Skip to content

Commit 7dbfa15

Browse files
authored
Merge pull request #99357 from mburke5678/cma-2172-prs-418
[enterprise-4.18] Custom Metrics Autoscaler compilation PR
2 parents feb0fd3 + 328f482 commit 7dbfa15

11 files changed

+221
-141
lines changed

_topic_maps/_topic_map.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2703,6 +2703,8 @@ Topics:
27032703
File: nodes-cma-autoscaling-custom-trigger
27042704
- Name: Understanding custom metrics autoscaler trigger authentications
27052705
File: nodes-cma-autoscaling-custom-trigger-auth
2706+
- Name: Understanding how to add custom metrics autoscalers
2707+
File: nodes-cma-autoscaling-custom-adding
27062708
- Name: Pausing the custom metrics autoscaler
27072709
File: nodes-cma-autoscaling-custom-pausing
27082710
- Name: Gathering audit logs
@@ -2711,8 +2713,6 @@ Topics:
27112713
File: nodes-cma-autoscaling-custom-debugging
27122714
- Name: Viewing Operator metrics
27132715
File: nodes-cma-autoscaling-custom-metrics
2714-
- Name: Understanding how to add custom metrics autoscalers
2715-
File: nodes-cma-autoscaling-custom-adding
27162716
- Name: Removing the Custom Metrics Autoscaler Operator
27172717
File: nodes-cma-autoscaling-custom-removing
27182718
- Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_osd.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1029,6 +1029,8 @@ Topics:
10291029
File: nodes-cma-autoscaling-custom-trigger
10301030
- Name: Understanding the custom metrics autoscaler trigger authentications
10311031
File: nodes-cma-autoscaling-custom-trigger-auth
1032+
- Name: Understanding how to add custom metrics autoscalers
1033+
File: nodes-cma-autoscaling-custom-adding
10321034
- Name: Pausing the custom metrics autoscaler
10331035
File: nodes-cma-autoscaling-custom-pausing
10341036
- Name: Gathering audit logs
@@ -1037,8 +1039,6 @@ Topics:
10371039
File: nodes-cma-autoscaling-custom-debugging
10381040
- Name: Viewing Operator metrics
10391041
File: nodes-cma-autoscaling-custom-metrics
1040-
- Name: Understanding how to add custom metrics autoscalers
1041-
File: nodes-cma-autoscaling-custom-adding
10421042
- Name: Removing the Custom Metrics Autoscaler Operator
10431043
File: nodes-cma-autoscaling-custom-removing
10441044
- Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_rosa.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1408,6 +1408,8 @@ Topics:
14081408
File: nodes-cma-autoscaling-custom-trigger
14091409
- Name: Understanding the custom metrics autoscaler trigger authentications
14101410
File: nodes-cma-autoscaling-custom-trigger-auth
1411+
- Name: Understanding how to add custom metrics autoscalers
1412+
File: nodes-cma-autoscaling-custom-adding
14111413
- Name: Pausing the custom metrics autoscaler
14121414
File: nodes-cma-autoscaling-custom-pausing
14131415
- Name: Gathering audit logs
@@ -1416,8 +1418,6 @@ Topics:
14161418
File: nodes-cma-autoscaling-custom-debugging
14171419
- Name: Viewing Operator metrics
14181420
File: nodes-cma-autoscaling-custom-metrics
1419-
- Name: Understanding how to add custom metrics autoscalers
1420-
File: nodes-cma-autoscaling-custom-adding
14211421
- Name: Removing the Custom Metrics Autoscaler Operator
14221422
File: nodes-cma-autoscaling-custom-removing
14231423
- Name: Controlling pod placement onto nodes (scheduling)

_topic_maps/_topic_map_rosa_hcp.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1082,6 +1082,8 @@ Topics:
10821082
File: nodes-cma-autoscaling-custom-trigger
10831083
- Name: Understanding the custom metrics autoscaler trigger authentications
10841084
File: nodes-cma-autoscaling-custom-trigger-auth
1085+
- Name: Understanding how to add custom metrics autoscalers
1086+
File: nodes-cma-autoscaling-custom-adding
10851087
- Name: Pausing the custom metrics autoscaler
10861088
File: nodes-cma-autoscaling-custom-pausing
10871089
- Name: Gathering audit logs
@@ -1090,8 +1092,6 @@ Topics:
10901092
File: nodes-cma-autoscaling-custom-debugging
10911093
- Name: Viewing Operator metrics
10921094
File: nodes-cma-autoscaling-custom-metrics
1093-
- Name: Understanding how to add custom metrics autoscalers
1094-
File: nodes-cma-autoscaling-custom-adding
10951095
- Name: Removing the Custom Metrics Autoscaler Operator
10961096
File: nodes-cma-autoscaling-custom-removing
10971097
- Name: Controlling pod placement onto nodes (scheduling)

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

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -140,12 +140,12 @@ spec:
140140
<8> Optional: Specifies the maximum number of replicas when scaling up. The default is `100`.
141141
<9> Optional: Specifies the minimum number of replicas when scaling down.
142142
<10> Optional: Specifies the parameters for audit logs. as described in the "Configuring audit logging" section.
143-
<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].
144-
<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:
145-
* Enter `static` to use the number of replicas specified by the `fallback.replicas` parameter.
143+
<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].
144+
<12> Optional: Specifies the replica count to be used if a fallback occurs. Enter one of the following options or omit the parameter:
145+
* Enter `static` to use the number of replicas specified by the `fallback.replicas` parameter. This is the default.
146146
* Enter `currentReplicas` to maintain the current number of replicas.
147-
* 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.
148-
* 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.
147+
* 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.
148+
* 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.
149149
<13> Optional: Specifies the interval in seconds to check each trigger on. The default is `30`.
150150
<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.
151151
<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:
193193
** If `False`, the custom metrics autoscaler is getting metrics.
194194
** 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.
195195
--
196-

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

Lines changed: 57 additions & 60 deletions
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,6 @@ These steps are not required for an external Prometheus source.
1818
You must perform the following tasks, as described in this section:
1919

2020
* Create a service account.
21-
* Create a secret that generates a token for the service account.
2221
* Create the trigger authentication.
2322
* Create a role.
2423
* Add that role to the service account.
@@ -45,7 +44,7 @@ $ oc project <project_name> <1>
4544
* If you are using a trigger authentication, specify the project with the object you want to scale.
4645
* If you are using a cluster trigger authentication, specify the `openshift-keda` project.
4746

48-
. Create a service account and token, if your cluster does not have one:
47+
. Create a service account if your cluster does not have one:
4948

5049
.. Create a `service account` object by using the following command:
5150
+
@@ -55,53 +54,6 @@ $ oc create serviceaccount thanos <1>
5554
----
5655
<1> Specifies the name of the service account.
5756

58-
.. Create a `secret` YAML to generate a service account token:
59-
+
60-
[source,yaml]
61-
----
62-
apiVersion: v1
63-
kind: Secret
64-
metadata:
65-
name: thanos-token
66-
annotations:
67-
kubernetes.io/service-account.name: thanos <1>
68-
type: kubernetes.io/service-account-token
69-
----
70-
<1> Specifies the name of the service account.
71-
72-
.. Create the secret object by using the following command:
73-
+
74-
[source,terminal]
75-
----
76-
$ oc create -f <file_name>.yaml
77-
----
78-
79-
.. Use the following command to locate the token assigned to the service account:
80-
+
81-
[source,terminal]
82-
----
83-
$ oc describe serviceaccount thanos <1>
84-
----
85-
+
86-
<1> Specifies the name of the service account.
87-
+
88-
--
89-
.Example output
90-
[source,terminal]
91-
----
92-
Name: thanos
93-
Namespace: <namespace_name>
94-
Labels: <none>
95-
Annotations: <none>
96-
Image pull secrets: thanos-dockercfg-nnwgj
97-
Mountable secrets: thanos-dockercfg-nnwgj
98-
Tokens: thanos-token <1>
99-
Events: <none>
100-
101-
----
102-
<1> Use this token in the trigger authentication.
103-
--
104-
10557
. Create a trigger authentication with the service account token:
10658

10759
.. Create a YAML file similar to the following:
@@ -113,23 +65,18 @@ kind: <authentication_method> <1>
11365
metadata:
11466
name: keda-trigger-auth-prometheus
11567
spec:
116-
secretTargetRef: <2>
117-
- parameter: bearerToken <3>
118-
name: thanos-token <4>
119-
key: token <5>
120-
- parameter: ca
121-
name: thanos-token
122-
key: ca.crt
68+
boundServiceAccountToken: <2>
69+
- parameter: bearerToken <3>
70+
serviceAccountName: thanos <4>
12371
----
12472
<1> Specifies one of the following trigger authentication methods:
12573
+
12674
* If you are using a trigger authentication, specify `TriggerAuthentication`. This example configures a trigger authentication.
12775
* If you are using a cluster trigger authentication, specify `ClusterTriggerAuthentication`.
12876
+
129-
<2> Specifies that this object uses a secret for authorization.
130-
<3> Specifies the authentication parameter to supply by using the token.
131-
<4> Specifies the name of the token to use.
132-
<5> Specifies the key in the token to use with the specified parameter.
77+
<2> Specifies that this trigger authentication uses a bound service account token for authorization when connecting to the metrics endpoint.
78+
<3> Specifies the authentication parameter to supply by using the token. Here, the example uses bearer authentication.
79+
<4> Specifies the name of the service account to use.
13380

13481
.. Create the CR object:
13582
+
@@ -221,3 +168,53 @@ You can now deploy a scaled object or scaled job to enable autoscaling for your
221168
* `triggers.metadata.authModes` must be `bearer`
222169
* `triggers.metadata.namespace` must be set to the namespace of the object to scale
223170
* `triggers.authenticationRef` must point to the trigger authentication resource specified in the previous step
171+
172+
////
173+
Hiding, might not need it. If so, place this as step 2.
174+
.. Create a `secret` YAML to generate a service account token:
175+
+
176+
[source,yaml]
177+
----
178+
apiVersion: v1
179+
kind: Secret
180+
metadata:
181+
name: thanos-token
182+
annotations:
183+
kubernetes.io/service-account.name: thanos <1>
184+
type: kubernetes.io/service-account-token
185+
----
186+
<1> Specifies the name of the service account.
187+
188+
.. Create the secret object by using the following command:
189+
+
190+
[source,terminal]
191+
----
192+
$ oc create -f <file_name>.yaml
193+
----
194+
195+
.. Use the following command to locate the token assigned to the service account:
196+
+
197+
[source,terminal]
198+
----
199+
$ oc describe serviceaccount thanos <1>
200+
----
201+
+
202+
<1> Specifies the name of the service account.
203+
+
204+
--
205+
.Example output
206+
[source,terminal]
207+
----
208+
Name: thanos
209+
Namespace: <namespace_name>
210+
Labels: <none>
211+
Annotations: <none>
212+
Image pull secrets: thanos-dockercfg-nnwgj
213+
Mountable secrets: thanos-dockercfg-nnwgj
214+
Tokens: thanos-token <1>
215+
Events: <none>
216+
217+
----
218+
<1> Use this token in the trigger authentication.
219+
--
220+
////

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

Lines changed: 44 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -12,43 +12,69 @@ You use trigger authentications and cluster trigger authentications by using a c
1212

1313
* The Custom Metrics Autoscaler Operator must be installed.
1414
15-
* If you are using a secret, the `Secret` object must exist, for example:
15+
* If you are using a bound service account token, the service account must exist.
16+
17+
* 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.
1618
+
17-
.Example secret
1819
[source,yaml]
1920
----
20-
apiVersion: v1
21-
kind: Secret
21+
apiVersion: rbac.authorization.k8s.io/v1
22+
kind: Role
23+
metadata:
24+
name: keda-operator-token-creator
25+
namespace: <namespace_name> <1>
26+
rules:
27+
- apiGroups:
28+
- ""
29+
resources:
30+
- serviceaccounts/token
31+
verbs:
32+
- create
33+
resourceNames:
34+
- thanos <2>
35+
---
36+
apiVersion: rbac.authorization.k8s.io/v1
37+
kind: RoleBinding
2238
metadata:
23-
name: my-secret
24-
data:
25-
user-name: <base64_USER_NAME>
26-
password: <base64_USER_PASSWORD>
39+
name: keda-operator-token-creator-binding
40+
namespace: <namespace_name> <3>
41+
roleRef:
42+
apiGroup: rbac.authorization.k8s.io
43+
kind: Role
44+
name: keda-operator-token-creator
45+
subjects:
46+
- kind: ServiceAccount
47+
name: keda-operator
48+
namespace: openshift-keda
2749
----
50+
<1> Specifies the namespace of the service account.
51+
<2> Specifies the name of the service account.
52+
<3> Specifies the namespace of the service account.
53+
54+
* If you are using a secret, the `Secret` object must exist.
2855
2956
.Procedure
3057

3158
. Create the `TriggerAuthentication` or `ClusterTriggerAuthentication` object.
3259

3360
.. Create a YAML file that defines the object:
3461
+
35-
.Example trigger authentication with a secret
62+
.Example trigger authentication with a bound service account token
3663
[source,yaml]
3764
----
3865
kind: TriggerAuthentication
3966
apiVersion: keda.sh/v1alpha1
4067
metadata:
4168
name: prom-triggerauthentication
42-
namespace: my-namespace
43-
spec:
44-
secretTargetRef:
45-
- parameter: user-name
46-
name: my-secret
47-
key: USER_NAME
48-
- parameter: password
49-
name: my-secret
50-
key: USER_PASSWORD
69+
namespace: my-namespace <1>
70+
spec:
71+
boundServiceAccountToken: <2>
72+
- parameter: token
73+
serviceAccountName: thanos <3>
5174
----
75+
<1> Specifies the namespace of the object you want to scale.
76+
<2> Specifies that this trigger authentication uses a bound service account token for authorization when connecting to the metrics endpoint.
77+
<3> Specifies the name of the service account to use.
5278

5379
.. Create the `TriggerAuthentication` object:
5480
+

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

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,6 +35,7 @@ spec:
3535
cortexOrgID: my-org <8>
3636
ignoreNullValues: "false" <9>
3737
unsafeSsl: "false" <10>
38+
timeout: 1000 <11>
3839
----
3940
<1> Specifies Prometheus as the trigger type.
4041
<2> Specifies the address of the Prometheus server. This example uses {product-title} monitoring.
@@ -51,7 +52,10 @@ spec:
5152
* If `false`, the certificate check is performed. This is the default behavior.
5253
* If `true`, the certificate check is not performed.
5354
+
55+
--
5456
[IMPORTANT]
5557
====
5658
Skipping the check is not recommended.
5759
====
60+
--
61+
<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.
Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * nodes/cma/nodes-cma-autoscaling-custom-trigger.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="nodes-cma-autoscaling-custom-trigger-workload_{context}"]
7+
= Understanding the Kubernetes workload trigger
8+
9+
You can scale pods based on the number of pods matching a specific label selector.
10+
11+
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.
12+
13+
The pod counts includes pods with a `Succeeded` or `Failed` phase.
14+
15+
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.
16+
17+
.Example scaled object with a Kubernetes workload trigger
18+
[source,yaml]
19+
----
20+
apiVersion: keda.sh/v1alpha1
21+
kind: ScaledObject
22+
metadata:
23+
name: workload-scaledobject
24+
namespace: my-namespace
25+
spec:
26+
triggers:
27+
- type: kubernetes-workload <1>
28+
metadata:
29+
podSelector: 'app=frontend' <2>
30+
value: '0.5' <3>
31+
activationValue: '3.1' <4>
32+
----
33+
<1> Specifies a Kubernetes workload trigger.
34+
<2> Specifies one or more pod selectors and/or set-based selectors, separated with commas, to use to get the pod count.
35+
<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:
36+
+
37+
----
38+
relation = (pods that match the selector) / (scaled workload pods)
39+
----
40+
+
41+
<4> Optional: Specifies the target value for scaler activation phase. The default is `0`.

0 commit comments

Comments
 (0)