[enterprise-4.18] Custom Metrics Autoscaler compilation PR

_topic_maps/_topic_map.yml

@@ -2703,6 +2703,8 @@ Topics:
     File: nodes-cma-autoscaling-custom-trigger
   - Name: Understanding custom metrics autoscaler trigger authentications
     File: nodes-cma-autoscaling-custom-trigger-auth
+  - Name: Understanding how to add custom metrics autoscalers
+    File: nodes-cma-autoscaling-custom-adding
   - Name: Pausing the custom metrics autoscaler
     File: nodes-cma-autoscaling-custom-pausing
   - Name: Gathering audit logs
@@ -2711,8 +2713,6 @@ Topics:
     File: nodes-cma-autoscaling-custom-debugging
   - Name: Viewing Operator metrics
     File: nodes-cma-autoscaling-custom-metrics
-  - Name: Understanding how to add custom metrics autoscalers
-    File: nodes-cma-autoscaling-custom-adding
   - Name: Removing the Custom Metrics Autoscaler Operator
     File: nodes-cma-autoscaling-custom-removing
 - Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_osd.yml

@@ -1029,6 +1029,8 @@ Topics:
     File: nodes-cma-autoscaling-custom-trigger
   - Name: Understanding the custom metrics autoscaler trigger authentications
     File: nodes-cma-autoscaling-custom-trigger-auth
+  - Name: Understanding how to add custom metrics autoscalers
+    File: nodes-cma-autoscaling-custom-adding
   - Name: Pausing the custom metrics autoscaler
     File: nodes-cma-autoscaling-custom-pausing
   - Name: Gathering audit logs
@@ -1037,8 +1039,6 @@ Topics:
     File: nodes-cma-autoscaling-custom-debugging
   - Name: Viewing Operator metrics
     File: nodes-cma-autoscaling-custom-metrics
-  - Name: Understanding how to add custom metrics autoscalers
-    File: nodes-cma-autoscaling-custom-adding
   - Name: Removing the Custom Metrics Autoscaler Operator
     File: nodes-cma-autoscaling-custom-removing
 - Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_rosa.yml

@@ -1408,6 +1408,8 @@ Topics:
     File: nodes-cma-autoscaling-custom-trigger
   - Name: Understanding the custom metrics autoscaler trigger authentications
     File: nodes-cma-autoscaling-custom-trigger-auth
+  - Name: Understanding how to add custom metrics autoscalers
+    File: nodes-cma-autoscaling-custom-adding
   - Name: Pausing the custom metrics autoscaler
     File: nodes-cma-autoscaling-custom-pausing
   - Name: Gathering audit logs
@@ -1416,8 +1418,6 @@ Topics:
     File: nodes-cma-autoscaling-custom-debugging
   - Name: Viewing Operator metrics
     File: nodes-cma-autoscaling-custom-metrics
-  - Name: Understanding how to add custom metrics autoscalers
-    File: nodes-cma-autoscaling-custom-adding
   - Name: Removing the Custom Metrics Autoscaler Operator
     File: nodes-cma-autoscaling-custom-removing
 - Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_rosa_hcp.yml

@@ -1082,6 +1082,8 @@ Topics:
     File: nodes-cma-autoscaling-custom-trigger
   - Name: Understanding the custom metrics autoscaler trigger authentications
     File: nodes-cma-autoscaling-custom-trigger-auth
+  - Name: Understanding how to add custom metrics autoscalers
+    File: nodes-cma-autoscaling-custom-adding
   - Name: Pausing the custom metrics autoscaler
     File: nodes-cma-autoscaling-custom-pausing
   - Name: Gathering audit logs
@@ -1090,8 +1092,6 @@ Topics:
     File: nodes-cma-autoscaling-custom-debugging
   - Name: Viewing Operator metrics
     File: nodes-cma-autoscaling-custom-metrics
-  - Name: Understanding how to add custom metrics autoscalers
-    File: nodes-cma-autoscaling-custom-adding
   - Name: Removing the Custom Metrics Autoscaler Operator
     File: nodes-cma-autoscaling-custom-removing
 - Name: Controlling pod placement onto nodes (scheduling)

modules/nodes-cma-autoscaling-custom-creating-workload.adoc

@@ -140,12 +140,12 @@ spec:
 <8> Optional: Specifies the maximum number of replicas when scaling up. The default is `100`.
 <9> Optional: Specifies the minimum number of replicas when scaling down.
 <10> Optional: Specifies the parameters for audit logs. as described in the "Configuring audit logging" section.
-<11> Optional: Specifies the number of replicas to fall back to if a scaler fails to get metrics from the source for the number of times defined by the `failureThreshold` parameter. For more information on fallback behavior, see the link:https://keda.sh/docs/2.7/concepts/scaling-deployments/#fallback[KEDA documentation].
-<12> Optional: Specifies the replica count to be used in the event of a fall back. Enter one of the following options or omit the parameter:
-* Enter `static` to use the number of replicas specified by the `fallback.replicas` parameter.
+<11> Optional: Specifies the number of replicas to fall back to if a scaler fails to get metrics from the source for the number of times defined by the `failureThreshold` parameter. For more information on fallback behavior, see the link:https://keda.sh/docs/latest/reference/scaledobject-spec/#fallback[KEDA documentation].
+<12> Optional: Specifies the replica count to be used if a fallback occurs. Enter one of the following options or omit the parameter:
+* Enter `static` to use the number of replicas specified by the `fallback.replicas` parameter. This is the default.
 * Enter `currentReplicas` to maintain the current number of replicas.
-* Enter `currentReplicasIfHigher` to maintain the current number of replicas, if that number is higher than the `fallback.replicas` parameter. If the current number is lower, use the `fallback.replicas` value.
-* Enter `currentReplicasIfLower` to maintain the current number of replicas, if that number is lower than the `fallback.replicas` parameter. If the current number is higher, use the `fallback.replicas` value.
+* Enter `currentReplicasIfHigher` to maintain the current number of replicas, if that number is higher than the `fallback.replicas` parameter. If the current number of replicas is lower than the `fallback.replicas` parameter, use the `fallback.replicas` value.
+* Enter `currentReplicasIfLower` to maintain the current number of replicas, if that number is lower than the `fallback.replicas` parameter. If the current number of replicas is higher than the `fallback.replicas` parameter, use the `fallback.replicas` value.
 <13> Optional: Specifies the interval in seconds to check each trigger on. The default is `30`.
 <14> Optional: Specifies whether to scale back the target resource to the original replica count after the scaled object is deleted. The default is `false`, which keeps the replica count as it is when the scaled object is deleted.
 <15> Optional: Specifies a name for the horizontal pod autoscaler. The default is `keda-hpa-{scaled-object-name}`.
@@ -193,4 +193,3 @@ Note the following fields in the output:
 ** If `False`, the custom metrics autoscaler is getting metrics.
 ** If `True`, the custom metrics autoscaler is getting metrics because there are no metrics or there is a problem in one or more of the objects you created.
 --
-

modules/nodes-cma-autoscaling-custom-prometheus-config.adoc

@@ -18,7 +18,6 @@ These steps are not required for an external Prometheus source.
 You must perform the following tasks, as described in this section:
 
 * Create a service account.
-* Create a secret that generates a token for the service account.
 * Create the trigger authentication.
 * Create a role.
 * Add that role to the service account.
@@ -45,7 +44,7 @@ $ oc project <project_name> <1>
 *  If you are using a trigger authentication, specify the project with the object you want to scale.
 *  If you are using a cluster trigger authentication, specify the `openshift-keda` project.
 
-. Create a service account and token, if your cluster does not have one:
+. Create a service account if your cluster does not have one:
 
 .. Create a `service account` object by using the following command:
 +
@@ -55,53 +54,6 @@ $ oc create serviceaccount thanos <1>
 ----
 <1> Specifies the name of the service account.
 
-.. Create a `secret` YAML to generate a service account token:
-+
-[source,yaml]
-----
-apiVersion: v1
-kind: Secret
-metadata:
-  name: thanos-token
-  annotations:
-    kubernetes.io/service-account.name: thanos <1>
-type: kubernetes.io/service-account-token
-----
-<1> Specifies the name of the service account.
-
-.. Create the secret object by using the following command:
-+
-[source,terminal]
-----
-$ oc create -f <file_name>.yaml
-----
-
-.. Use the following command to locate the token assigned to the service account:
-+
-[source,terminal]
-----
-$ oc describe serviceaccount thanos <1>
-----
-+
-<1> Specifies the name of the service account.
-+
---
-.Example output
-[source,terminal]
-----
-Name:                thanos
-Namespace:           <namespace_name>
-Labels:              <none>
-Annotations:         <none>
-Image pull secrets:  thanos-dockercfg-nnwgj
-Mountable secrets:   thanos-dockercfg-nnwgj
-Tokens:              thanos-token <1>
-Events:              <none>
-
-----
-<1> Use this token in the trigger authentication.
---
-
 . Create a trigger authentication with the service account token:
 
 .. Create a YAML file similar to the following:
@@ -113,23 +65,18 @@ kind: <authentication_method> <1>
 metadata:
   name: keda-trigger-auth-prometheus
 spec:
-  secretTargetRef: <2>
-  - parameter: bearerToken <3>
-    name: thanos-token <4>
-    key: token <5>
-  - parameter: ca
-    name: thanos-token
-    key: ca.crt
+  boundServiceAccountToken: <2>
+    - parameter: bearerToken <3>
+      serviceAccountName: thanos <4>
 ----
 <1> Specifies one of the following trigger authentication methods:
 +
 *  If you are using a trigger authentication, specify `TriggerAuthentication`. This example configures a trigger authentication.
 *  If you are using a cluster trigger authentication, specify `ClusterTriggerAuthentication`.
 +
-<2> Specifies that this object uses a secret for authorization.
-<3> Specifies the authentication parameter to supply by using the token.
-<4> Specifies the name of the token to use.
-<5> Specifies the key in the token to use with the specified parameter.
+<2> Specifies that this trigger authentication uses a bound service account token for authorization when connecting to the metrics endpoint.
+<3> Specifies the authentication parameter to supply by using the token. Here, the example uses bearer authentication.
+<4> Specifies the name of the service account to use.
 
 .. Create the CR object:
 +
@@ -221,3 +168,53 @@ You can now deploy a scaled object or scaled job to enable autoscaling for your
 * `triggers.metadata.authModes` must be `bearer`
 * `triggers.metadata.namespace` must be set to the namespace of the object to scale
 * `triggers.authenticationRef` must point to the trigger authentication resource specified in the previous step
+
+////
+Hiding, might not need it. If so, place this as step 2.
+.. Create a `secret` YAML to generate a service account token:
++
+[source,yaml]
+----
+apiVersion: v1
+kind: Secret
+metadata:
+  name: thanos-token
+  annotations:
+    kubernetes.io/service-account.name: thanos <1>
+type: kubernetes.io/service-account-token
+----
+<1> Specifies the name of the service account.
+
+.. Create the secret object by using the following command:
++
+[source,terminal]
+----
+$ oc create -f <file_name>.yaml
+----
+
+.. Use the following command to locate the token assigned to the service account:
++
+[source,terminal]
+----
+$ oc describe serviceaccount thanos <1>
+----
++
+<1> Specifies the name of the service account.
++
+--
+.Example output
+[source,terminal]
+----
+Name:                thanos
+Namespace:           <namespace_name>
+Labels:              <none>
+Annotations:         <none>
+Image pull secrets:  thanos-dockercfg-nnwgj
+Mountable secrets:   thanos-dockercfg-nnwgj
+Tokens:              thanos-token <1>
+Events:              <none>
+
+----
+<1> Use this token in the trigger authentication.
+--
+////

modules/nodes-cma-autoscaling-custom-trigger-auth-using.adoc

@@ -12,43 +12,69 @@ You use trigger authentications and cluster trigger authentications by using a c
 
 * The Custom Metrics Autoscaler Operator must be installed.
 
-* If you are using a secret, the `Secret` object must exist, for example:
+* If you are using a bound service account token, the service account must exist.
+
+* If you are using a bound service account token, a role-based access control (RBAC) object that enables the Custom Metrics Autoscaler Operator to request service account tokens from the service account must exist.
 +
-.Example secret
 [source,yaml]
 ----
-apiVersion: v1
-kind: Secret
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: keda-operator-token-creator
+  namespace: <namespace_name> <1>
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - serviceaccounts/token
+  verbs:
+  - create
+  resourceNames:
+  - thanos <2>
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
 metadata:
-  name: my-secret
-data:
-  user-name: <base64_USER_NAME>
-  password: <base64_USER_PASSWORD>
+  name: keda-operator-token-creator-binding
+  namespace: <namespace_name> <3>
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: keda-operator-token-creator
+subjects:
+- kind: ServiceAccount
+  name: keda-operator
+  namespace: openshift-keda
 ----
+<1> Specifies the namespace of the service account.
+<2> Specifies the name of the service account.
+<3> Specifies the namespace of the service account.
+
+* If you are using a secret, the `Secret` object must exist.
 
 .Procedure
 
 . Create the `TriggerAuthentication` or  `ClusterTriggerAuthentication` object.
 
 .. Create a YAML file that defines the object:
 +
-.Example trigger authentication with a secret
+.Example trigger authentication with a bound service account token
 [source,yaml]
 ----
 kind: TriggerAuthentication
 apiVersion: keda.sh/v1alpha1
 metadata:
   name: prom-triggerauthentication
-  namespace: my-namespace
-spec:
-  secretTargetRef:
-  - parameter: user-name
-    name: my-secret
-    key: USER_NAME
-  - parameter: password
-    name: my-secret
-    key: USER_PASSWORD
+  namespace: my-namespace <1>
+  spec:
+  boundServiceAccountToken: <2>
+    - parameter: token
+      serviceAccountName: thanos <3>
 ----
+<1> Specifies the namespace of the object you want to scale.
+<2> Specifies that this trigger authentication uses a bound service account token for authorization when connecting to the metrics endpoint.
+<3> Specifies the name of the service account to use.
 
 .. Create the `TriggerAuthentication` object:
 +

modules/nodes-cma-autoscaling-custom-trigger-prom.adoc

@@ -35,6 +35,7 @@ spec:
       cortexOrgID: my-org <8>
       ignoreNullValues: "false" <9>
       unsafeSsl: "false" <10>
+      timeout: 1000 <11>
 ----
 <1> Specifies Prometheus as the trigger type.
 <2> Specifies the address of the Prometheus server. This example uses  {product-title} monitoring.
@@ -51,7 +52,10 @@ spec:
      * If `false`, the certificate check is performed. This is the default behavior.
      * If `true`, the certificate check is not performed.
 +
+--
 [IMPORTANT]
 ====
 Skipping the check is not recommended.
 ====
+--
+<11> Optional: Specifies an HTTP request timeout in milliseconds for the HTTP client used by this Prometheus trigger. This value overrides any global timeout setting.

modules/nodes-cma-autoscaling-custom-trigger-workload.adoc

@@ -0,0 +1,41 @@
+// Module included in the following assemblies:
+//
+// * nodes/cma/nodes-cma-autoscaling-custom-trigger.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nodes-cma-autoscaling-custom-trigger-workload_{context}"]
+= Understanding the Kubernetes workload trigger
+
+You can scale pods based on the number of pods matching a specific label selector.
+
+The Custom Metrics Autoscaler Operator tracks the number of pods with a specific label that are in the same namespace, then calculates a _relation_ based on the number of labeled pods to the pods for the scaled object. Using this relation, the Custom Metrics Autoscaler Operator scales the object according to the scaling policy in the `ScaledObject` or `ScaledJob` specification.
+
+The pod counts includes pods with a `Succeeded` or `Failed` phase.
+
+For example, if you have a `frontend` deployment and a `backend` deployment. You can use a `kubernetes-workload` trigger to scale the `backend` deployment based on the number of `frontend` pods. If number of `frontend` pods goes up, the Operator would scale the `backend` pods to maintain the specified ratio. In this example, if there are 10 pods with the `app=frontend` pod selector, the Operator scales the backend pods to 5 in order to maintain the `0.5` ratio set in the scaled object.
+
+.Example scaled object with a Kubernetes workload trigger
+[source,yaml]
+----
+apiVersion: keda.sh/v1alpha1
+kind: ScaledObject
+metadata:
+  name: workload-scaledobject
+  namespace: my-namespace
+spec:
+  triggers:
+  - type: kubernetes-workload <1>
+    metadata:
+      podSelector: 'app=frontend' <2>
+      value: '0.5' <3>
+      activationValue: '3.1' <4>
+----
+<1> Specifies a Kubernetes workload trigger.
+<2> Specifies one or more pod selectors and/or set-based selectors, separated with commas, to use to get the pod count.
+<3> Specifies the target relation between the scaled workload and the number of pods that match the selector. The relation is calculated following the following formula: 
++
+----
+relation = (pods that match the selector) / (scaled workload pods)
+----
++
+<4> Optional: Specifies the target value for scaler activation phase. The default is `0`.