diff --git a/content/docs/2.17/authentication-providers/azure-key-vault.md b/content/docs/2.17/authentication-providers/azure-key-vault.md index 41b6588fb..674229956 100644 --- a/content/docs/2.17/authentication-providers/azure-key-vault.md +++ b/content/docs/2.17/authentication-providers/azure-key-vault.md @@ -20,7 +20,7 @@ The `cloud` parameter can be used to specify cloud environments besides `Azure P azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. - provider: azure | azure-workload # Required. + provider: azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. diff --git a/content/docs/2.17/concepts/authentication.md b/content/docs/2.17/concepts/authentication.md index 6b602a8c4..d751e01ec 100644 --- a/content/docs/2.17/concepts/authentication.md +++ b/content/docs/2.17/concepts/authentication.md @@ -115,12 +115,12 @@ spec: 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. + 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. + provider: azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. diff --git a/content/docs/2.17/concepts/scaling-deployments.md b/content/docs/2.17/concepts/scaling-deployments.md index db6e69140..63a5f6661 100644 --- a/content/docs/2.17/concepts/scaling-deployments.md +++ b/content/docs/2.17/concepts/scaling-deployments.md @@ -39,7 +39,7 @@ The only constraint is that the target `Custom Resource` must define `/scale` [s 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. +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. diff --git a/content/docs/2.17/deploy.md b/content/docs/2.17/deploy.md index 09a4be87a..5f2517329 100644 --- a/content/docs/2.17/deploy.md +++ b/content/docs/2.17/deploy.md @@ -8,7 +8,7 @@ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - Operator Hub - YAML declarations -> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.27 and higher +> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.28 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. diff --git a/content/docs/2.17/integrations/_index.md b/content/docs/2.17/integrations/_index.md new file mode 100644 index 000000000..745b6065b --- /dev/null +++ b/content/docs/2.17/integrations/_index.md @@ -0,0 +1,8 @@ ++++ +title = "Integrations" +weight = 6 ++++ + +An overview of tools/products integrating with KEDA: + +{{< integrations >}} diff --git a/content/docs/2.17/operate/istio-integration.md b/content/docs/2.17/integrations/istio-integration.md similarity index 98% rename from content/docs/2.17/operate/istio-integration.md rename to content/docs/2.17/integrations/istio-integration.md index 78427324c..413cf3ae0 100644 --- a/content/docs/2.17/operate/istio-integration.md +++ b/content/docs/2.17/integrations/istio-integration.md @@ -1,7 +1,8 @@ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" -weight = 100 +availability = "v2.14+" +project = "Istio" +++ ## Overview @@ -60,4 +61,4 @@ 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. \ No newline at end of file +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. diff --git a/content/docs/2.17/operate/opentelemetry.md b/content/docs/2.17/integrations/opentelemetry.md similarity index 98% rename from content/docs/2.17/operate/opentelemetry.md rename to content/docs/2.17/integrations/opentelemetry.md index f1c5459da..1db48fb1e 100644 --- a/content/docs/2.17/operate/opentelemetry.md +++ b/content/docs/2.17/integrations/opentelemetry.md @@ -1,7 +1,8 @@ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" -weight = 100 +availability = "v2.12+" +project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) @@ -54,4 +55,4 @@ The following metrics are exposed as well, but are deprecated and will be remove | `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. | \ No newline at end of file +| `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. | diff --git a/content/docs/2.17/operate/prometheus.md b/content/docs/2.17/integrations/prometheus.md similarity index 99% rename from content/docs/2.17/operate/prometheus.md rename to content/docs/2.17/integrations/prometheus.md index b6dac773a..87b8117b1 100644 --- a/content/docs/2.17/operate/prometheus.md +++ b/content/docs/2.17/integrations/prometheus.md @@ -1,7 +1,8 @@ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" -weight = 100 +availability = "v2.0+" +project = "Prometheus" +++ ## Prometheus Exporter Metrics diff --git a/content/docs/2.17/operate/_index.md b/content/docs/2.17/operate/_index.md index dac7c02f2..bfacd27cb 100644 --- a/content/docs/2.17/operate/_index.md +++ b/content/docs/2.17/operate/_index.md @@ -6,10 +6,8 @@ weight = 1 We provide guidance and requirements around various areas to operate KEDA: -- Admission Webhooks ([link](./admission-webhooks)) -- Cluster ([link](./cluster)) -- Kubernetes Events ([link](../reference/events)) -- KEDA Metrics Server ([link](./metrics-server)) -- Integrate with Prometheus ([link](./prometheus)) -- Integrate with OpenTelemetry Collector (Experimental) ([link](./opentelemetry)) -- Security ([link](./security)) +- [Admission Webhooks](./admission-webhooks) +- [Cluster](./cluster) +- [Kubernetes Events](../reference/events) +- [KEDA Metrics Server](./metrics-server) +- [Security](./security) diff --git a/content/docs/2.17/operate/admission-webhooks.md b/content/docs/2.17/operate/admission-webhooks.md index 9b3b753ca..74545b8c7 100644 --- a/content/docs/2.17/operate/admission-webhooks.md +++ b/content/docs/2.17/operate/admission-webhooks.md @@ -9,3 +9,110 @@ weight = 100 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 +``` \ No newline at end of file diff --git a/content/docs/2.17/operate/cloud-events.md b/content/docs/2.17/operate/cloud-events.md index 7334e134d..4ae54d5b5 100644 --- a/content/docs/2.17/operate/cloud-events.md +++ b/content/docs/2.17/operate/cloud-events.md @@ -84,7 +84,7 @@ Here is an overview of the supported authentication types: - `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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 @@ -117,4 +117,10 @@ eventSubscription: #Optional. Submit included/excluded event types will filter e | `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 | \ No newline at end of file +| `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 | \ No newline at end of file diff --git a/content/docs/2.17/operate/cluster.md b/content/docs/2.17/operate/cluster.md index 920584bea..524ff1eaa 100644 --- a/content/docs/2.17/operate/cluster.md +++ b/content/docs/2.17/operate/cluster.md @@ -16,7 +16,8 @@ As a reference, this compatibility matrix shows supported k8s versions per KEDA | KEDA | Kubernetes | | ----- | ------------- | -| v2.16 | TBD | +| v2.17 | TBD | +| v2.16 | v1.28 - v1.30 | | v2.15 | v1.28 - v1.30 | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | diff --git a/content/docs/2.17/reference/_index.md b/content/docs/2.17/reference/_index.md index 82fc53448..14b0e6a6b 100644 --- a/content/docs/2.17/reference/_index.md +++ b/content/docs/2.17/reference/_index.md @@ -8,6 +8,6 @@ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Kubernetes Events](./events) -- [Firewall requirements] +- [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) -- [Glossary](./glossary.md) \ No newline at end of file +- [Glossary](./glossary.md) diff --git a/content/docs/2.17/reference/scaledjob-spec.md b/content/docs/2.17/reference/scaledjob-spec.md index 43fe6a6b0..3f056efa1 100644 --- a/content/docs/2.17/reference/scaledjob-spec.md +++ b/content/docs/2.17/reference/scaledjob-spec.md @@ -5,9 +5,7 @@ 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). +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 diff --git a/content/docs/2.17/reference/scaledobject-spec.md b/content/docs/2.17/reference/scaledobject-spec.md index 0fb899dfc..74a5200d5 100644 --- a/content/docs/2.17/reference/scaledobject-spec.md +++ b/content/docs/2.17/reference/scaledobject-spec.md @@ -70,11 +70,15 @@ To scale Kubernetes Deployments only `name` need be specified. To scale a differ ```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. +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 @@ -83,20 +87,20 @@ This is the interval to check each trigger on. By default, KEDA will check each 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/../concepts/scaling-deployments.md#support-for-cooldowndelay). +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 + 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. +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`.) +**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 @@ -242,7 +246,7 @@ For examples of this feature see section [Scaling Modifiers](../concepts/scaling 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](../operate/prometheus.md). By default, the name is generated from the trigger type. (Optional) +- **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) diff --git a/content/docs/2.17/scalers/apache-kafka.md b/content/docs/2.17/scalers/apache-kafka.md index 15414f5d5..8197d1fc0 100644 --- a/content/docs/2.17/scalers/apache-kafka.md +++ b/content/docs/2.17/scalers/apache-kafka.md @@ -100,6 +100,7 @@ partition will be scaled to zero. See the [discussion](https://github.com/kedaco - `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 negotation, 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) diff --git a/content/docs/2.17/scalers/aws-cloudwatch.md b/content/docs/2.17/scalers/aws-cloudwatch.md index b0532b72c..05f448157 100644 --- a/content/docs/2.17/scalers/aws-cloudwatch.md +++ b/content/docs/2.17/scalers/aws-cloudwatch.md @@ -116,27 +116,6 @@ The user or role used to authenticate with AWS CloudWatch must have the `cloudwa } ``` -This can be further scoped to specific namespaces, by using the `cloudwatch:namespace` condition key. For example, to only allow access to the `AWS/EC2` metric namespace: - -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AllowCloudWatchGetMetricData", - "Effect": "Allow", - "Action": "cloudwatch:GetMetricData", - "Resource": "*", - "Condition": { - "StringEquals": { - "cloudwatch:namespace": "AWS/EC2" - } - } - } - ] -} -``` - For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example diff --git a/content/docs/2.17/scalers/azure-app-insights.md b/content/docs/2.17/scalers/azure-app-insights.md index 234a00f32..cf53d5e45 100644 --- a/content/docs/2.17/scalers/azure-app-insights.md +++ b/content/docs/2.17/scalers/azure-app-insights.md @@ -76,7 +76,7 @@ The principal will need `Monitoring Reader` access to query metrics from the App **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. +[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 @@ -112,7 +112,7 @@ spec: key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: - provider: azure | azure-workload + provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject diff --git a/content/docs/2.17/scalers/azure-data-explorer.md b/content/docs/2.17/scalers/azure-data-explorer.md index 6493bafd1..787c05188 100644 --- a/content/docs/2.17/scalers/azure-data-explorer.md +++ b/content/docs/2.17/scalers/azure-data-explorer.md @@ -77,7 +77,7 @@ The AD identity that will be used requires `DatabaseViewer` role to query metric **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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Examples @@ -144,7 +144,7 @@ metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: - provider: azure | azure-workload + provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject diff --git a/content/docs/2.17/scalers/azure-event-hub.md b/content/docs/2.17/scalers/azure-event-hub.md index 926438526..cb1601cf3 100644 --- a/content/docs/2.17/scalers/azure-event-hub.md +++ b/content/docs/2.17/scalers/azure-event-hub.md @@ -80,7 +80,7 @@ You can authenticate by using pod identity or connection string authentication. **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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 @@ -90,7 +90,7 @@ metadata: namespace: default spec: podIdentity: - provider: Azure | azure-workload + 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. diff --git a/content/docs/2.17/scalers/azure-log-analytics.md b/content/docs/2.17/scalers/azure-log-analytics.md index c7743db27..26a75a522 100644 --- a/content/docs/2.17/scalers/azure-log-analytics.md +++ b/content/docs/2.17/scalers/azure-log-analytics.md @@ -152,7 +152,7 @@ You can use `TriggerAuthentication` CRD to configure the authentication by provi 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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example @@ -248,7 +248,7 @@ metadata: namespace: kedaloganalytics spec: podIdentity: - provider: azure | azure-workload + provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject diff --git a/content/docs/2.17/scalers/azure-monitor.md b/content/docs/2.17/scalers/azure-monitor.md index 156aa1099..330c583de 100644 --- a/content/docs/2.17/scalers/azure-monitor.md +++ b/content/docs/2.17/scalers/azure-monitor.md @@ -73,7 +73,7 @@ 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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example @@ -100,7 +100,7 @@ spec: key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: - provider: azure | azure-workload + provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject diff --git a/content/docs/2.17/scalers/azure-pipelines.md b/content/docs/2.17/scalers/azure-pipelines.md index 3f8fa4373..cbb532b34 100644 --- a/content/docs/2.17/scalers/azure-pipelines.md +++ b/content/docs/2.17/scalers/azure-pipelines.md @@ -64,7 +64,7 @@ As an alternative to using environment variables, you can authenticate with Azur **Pod Identity Authentication** -[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### How to determine your pool ID diff --git a/content/docs/2.17/scalers/azure-service-bus.md b/content/docs/2.17/scalers/azure-service-bus.md index e7b9c6bf3..80873efbb 100644 --- a/content/docs/2.17/scalers/azure-service-bus.md +++ b/content/docs/2.17/scalers/azure-service-bus.md @@ -69,7 +69,7 @@ You can authenticate by using pod identity or connection string authentication. **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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example @@ -82,7 +82,7 @@ metadata: name: azure-servicebus-auth spec: podIdentity: - provider: azure | azure-workload + provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject diff --git a/content/docs/2.17/scalers/azure-storage-blob.md b/content/docs/2.17/scalers/azure-storage-blob.md index 05bdbb220..1f895ad3b 100644 --- a/content/docs/2.17/scalers/azure-storage-blob.md +++ b/content/docs/2.17/scalers/azure-storage-blob.md @@ -56,7 +56,7 @@ You can authenticate by using pod identity or connection string authentication. **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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. - `accountName` - Name of the Azure Storage Account. @@ -69,7 +69,7 @@ metadata: name: azure-blob-auth spec: podIdentity: - provider: azure | azure-workload + provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject diff --git a/content/docs/2.17/scalers/azure-storage-queue.md b/content/docs/2.17/scalers/azure-storage-queue.md index a95618537..ef55c5983 100644 --- a/content/docs/2.17/scalers/azure-storage-queue.md +++ b/content/docs/2.17/scalers/azure-storage-queue.md @@ -46,7 +46,7 @@ You can authenticate by using pod identity or connection string authentication. **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. +[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example @@ -57,7 +57,7 @@ metadata: name: azure-queue-auth spec: podIdentity: - provider: azure | azure-workload + provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject diff --git a/content/docs/2.17/scalers/beanstalkd.md b/content/docs/2.17/scalers/beanstalkd.md new file mode 100644 index 000000000..6998b9d0a --- /dev/null +++ b/content/docs/2.17/scalers/beanstalkd.md @@ -0,0 +1,83 @@ ++++ +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" +``` diff --git a/content/docs/2.17/scalers/cpu.md b/content/docs/2.17/scalers/cpu.md index ad4efa3e2..7fc63a0bc 100644 --- a/content/docs/2.17/scalers/cpu.md +++ b/content/docs/2.17/scalers/cpu.md @@ -40,7 +40,7 @@ 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' + 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 ``` diff --git a/content/docs/2.17/scalers/datadog.md b/content/docs/2.17/scalers/datadog.md index 9e7bd4a4d..222e70563 100644 --- a/content/docs/2.17/scalers/datadog.md +++ b/content/docs/2.17/scalers/datadog.md @@ -141,13 +141,16 @@ spec: key: token - parameter: datadogNamespace name: datadog-config - key: namespace + 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 diff --git a/content/docs/2.17/scalers/elasticsearch.md b/content/docs/2.17/scalers/elasticsearch.md index 95ee76d6c..c53b22f35 100644 --- a/content/docs/2.17/scalers/elasticsearch.md +++ b/content/docs/2.17/scalers/elasticsearch.md @@ -3,15 +3,15 @@ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" -description = "Scale applications based on elasticsearch search template query result." +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. +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: +The trigger always requires the following information, but requires either only searchTemplateName **or** only query: ```yaml triggers: @@ -22,6 +22,7 @@ triggers: 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" @@ -33,11 +34,12 @@ triggers: - `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` - Comma separated list of indexes to run the search template query on. +- `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 multiples params separated by a semicolon character ( `;` ). +- `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) @@ -57,9 +59,9 @@ You can authenticate by using a username/password or apiKey/cloudID if you're us - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. -### Example +### Examples -Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. +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 @@ -100,3 +102,74 @@ spec: 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 +``` diff --git a/content/docs/2.17/scalers/etcd.md b/content/docs/2.17/scalers/etcd.md index f02da9ba3..b28ed7b1b 100644 --- a/content/docs/2.17/scalers/etcd.md +++ b/content/docs/2.17/scalers/etcd.md @@ -20,6 +20,8 @@ This specification describes the `etcd` trigger that scales based on an etcd key value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' + usernameFromEnv: # Optional + passwordFromEnv: # Optional ``` **Parameter list:** @@ -29,11 +31,18 @@ This specification describes the `etcd` trigger that scales based on an etcd key - `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:** @@ -46,7 +55,7 @@ You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It ### Example -Your etcd cluster no TLS auth: +Your etcd cluster no auth: ```yaml apiVersion: keda.sh/v1alpha1 @@ -65,6 +74,50 @@ spec: 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 diff --git a/content/docs/2.17/scalers/github-runner.md b/content/docs/2.17/scalers/github-runner.md index f8da2f8ce..6a8cbeaf1 100644 --- a/content/docs/2.17/scalers/github-runner.md +++ b/content/docs/2.17/scalers/github-runner.md @@ -25,6 +25,8 @@ triggers: 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 @@ -42,6 +44,7 @@ triggers: - `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) @@ -56,6 +59,7 @@ the scaler will use the value from the environment variable. The environment var - `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) @@ -95,7 +99,7 @@ The scaler will query the GitHub API to get the number of queued jobs in the spe 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. +- **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** diff --git a/content/docs/2.17/scalers/ibm-mq.md b/content/docs/2.17/scalers/ibm-mq.md index 210b72ba7..32d0b0065 100644 --- a/content/docs/2.17/scalers/ibm-mq.md +++ b/content/docs/2.17/scalers/ibm-mq.md @@ -28,7 +28,8 @@ triggers: **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` - Name of the Queue defined from which messages will be consumed. +- `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) diff --git a/content/docs/2.17/scalers/memory.md b/content/docs/2.17/scalers/memory.md index af6c76a4c..c95ecf5bc 100644 --- a/content/docs/2.17/scalers/memory.md +++ b/content/docs/2.17/scalers/memory.md @@ -40,7 +40,7 @@ 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' + 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 ``` diff --git a/content/docs/2.17/scalers/prometheus.md b/content/docs/2.17/scalers/prometheus.md index a0750edd6..e72cf3668 100644 --- a/content/docs/2.17/scalers/prometheus.md +++ b/content/docs/2.17/scalers/prometheus.md @@ -87,7 +87,7 @@ To gain a better understanding of creating a Prometheus trigger for Amazon Manag #### 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. +- [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 retreived 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. @@ -406,7 +406,7 @@ metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: - provider: azure | azure-workload # use "azure" for pod identity and "azure-workload" for workload identity + provider: azure-workload identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 diff --git a/content/docs/2.17/scalers/rabbitmq-queue.md b/content/docs/2.17/scalers/rabbitmq-queue.md index 1e65d7dd5..e2cc20e20 100644 --- a/content/docs/2.17/scalers/rabbitmq-queue.md +++ b/content/docs/2.17/scalers/rabbitmq-queue.md @@ -25,6 +25,8 @@ triggers: # 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 ``` @@ -48,6 +50,8 @@ triggers: 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. @@ -70,6 +74,15 @@ TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: > 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) @@ -125,6 +138,54 @@ spec: 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 diff --git a/content/docs/2.17/scalers/selenium-grid-scaler.md b/content/docs/2.17/scalers/selenium-grid-scaler.md index d30c30aa9..6ce9d281a 100644 --- a/content/docs/2.17/scalers/selenium-grid-scaler.md +++ b/content/docs/2.17/scalers/selenium-grid-scaler.md @@ -1,7 +1,7 @@ +++ title = "Selenium Grid Scaler" availability = "v2.4+" -maintainer = "Volvo Cars" +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" @@ -29,13 +29,20 @@ triggers: **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. +- `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. - `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) +- `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 @@ -105,6 +112,28 @@ spec: sessionBrowserName: 'msedge' ``` +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-chrome-node +spec: + maxReplicaCount: 8 + scaleTargetRef: + name: selenium-chrome-node + triggers: + - type: selenium-grid + metadata: + url: 'http://selenium-hub:4444/graphql' + browserName: 'chrome' + nodeMaxSessions: 4 +``` + 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 @@ -152,6 +181,8 @@ spec: 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 @@ -162,6 +193,8 @@ metadata: 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 @@ -173,6 +206,12 @@ spec: - 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 diff --git a/content/docs/2.17/setupscaler.md b/content/docs/2.17/setupscaler.md new file mode 100644 index 000000000..a8efd7078 --- /dev/null +++ b/content/docs/2.17/setupscaler.md @@ -0,0 +1,120 @@ ++++ +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](https://keda.sh/docs/2.14/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](https://keda.sh/docs/2.14/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":} + ```