Chapter 3. Automatically scaling pods with the Custom Metrics Autoscaler Operator

Specifies Prometheus as the trigger type.

Specifies the address of the Prometheus server. This example uses OpenShift Container Platform monitoring.

Optional: Specifies the namespace of the object you want to scale. This parameter is mandatory if using OpenShift Container Platform monitoring as a source for the metrics.

Specifies the name to identify the metric in the external.metrics.k8s.io API. If you are using more than one trigger, all metric names must be unique.

5

Specifies the value that triggers scaling. Must be specified as a quoted string value.

6

Specifies the Prometheus query to use.

7

Specifies the authentication method to use. Prometheus scalers support bearer authentication (bearer), basic authentication (basic), or TLS authentication (tls). You configure the specific authentication parameters in a trigger authentication, as discussed in a following section. As needed, you can also use a secret.

8

Optional: Passes the X-Scope-OrgID header to multi-tenant Cortex or Mimir storage for Prometheus. This parameter is required only with multi-tenant Prometheus storage, to indicate which data Prometheus should return.

9

Optional: Specifies how the trigger should proceed if the Prometheus target is lost.

If
```
true
```
, the trigger continues to operate if the Prometheus target is lost. This is the default behavior.
If
```
false
```
, the trigger returns an error if the Prometheus target is lost.

10

Optional: Specifies whether the certificate check should be skipped. For example, you might skip the check if you use self-signed certificates at the Prometheus endpoint.

If
```
true
```
, the certificate check is performed.
If
```
false
```
, the certificate check is not performed. This is the default behavior.

3.4.1.1. Configuring the custom metrics autoscaler to use OpenShift Container Platform monitoring
Copia collegamento

You can use the installed OpenShift Container Platform Prometheus monitoring as a source for the metrics used by the custom metrics autoscaler. However, there are some additional configurations you must perform.

Note

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 to get a token.
Create a role.
Add that role to the service account.
Reference the token in the trigger authentication object used by Prometheus.

Prerequisites

OpenShift Container Platform monitoring must be installed.
Monitoring of user-defined workloads must be enabled in OpenShift Container Platform monitoring, as described in the Creating a user-defined workload monitoring config map section.
The Custom Metrics Autoscaler Operator must be installed.

Procedure

Change to the project with the object you want to scale:
```
$ oc project my-project
```
Use the following command to create a service account, if your cluster does not have one:
```
$ oc create serviceaccount <service_account>
```
where:
<service_account>
Specifies the name of the service account.

Use the following command to locate the token assigned to the service account:

$ oc describe serviceaccount <service_account>

where:

<service_account>: Specifies the name of the service account.

Example output

Name:                thanos
Namespace:           my-project
Labels:              <none>
Annotations:         <none>
Image pull secrets:  thanos-dockercfg-nnwgj
Mountable secrets:   thanos-dockercfg-nnwgj
Tokens:              thanos-token-9g4n5

1


Events:              <none>

1: Use this token in the trigger authentication.

Create a trigger authentication with the service account token:
1. Create a YAML file similar to the following:
  apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-prometheus spec: secretTargetRef:
  1
  - parameter: bearerToken
  2
  name: thanos-token-9g4n5
  3
  key: token
  4
  - parameter: ca name: thanos-token-9g4n5 key: ca.crt
  1
  Specifies that this object uses a secret for authorization.
  2
  Specifies the authentication parameter to supply by using the token.
  3
  Specifies the name of the token to use.
  4
  Specifies the key in the token to use with the specified parameter.
2. Create the CR object:
  $ oc create -f <file-name>.yaml

Create a role for reading Thanos metrics:

Create a YAML file with the following parameters:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: thanos-metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

Create the CR object:
```
$ oc create -f <file-name>.yaml
```

Create a role binding for reading Thanos metrics:

Create a YAML file similar to the following:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: thanos-metrics-reader

1


  namespace: my-project

2


roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: thanos-metrics-reader
subjects:
- kind: ServiceAccount
  name: thanos

3


  namespace: my-project

4

1: Specifies the name of the role you created.
2: Specifies the namespace of the object you want to scale.
3: Specifies the name of the service account to bind to the role.
4: Specifies the namespace of the object you want to scale.

Create the CR object:
```
$ oc create -f <file-name>.yaml
```

You can now deploy a scaled object or scaled job to enable autoscaling for your application, as described in "Understanding how to add custom metrics autoscalers". To use OpenShift Container Platform monitoring as the source, in the trigger, or scaler, you must include the following parameters:

```
triggers.type
```
must be
```
prometheus
```

triggers.metadata.serverAddress

must be

https://thanos-querier.openshift-monitoring.svc.cluster.local:9092

```
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

3.4.2. Understanding the CPU trigger
Copia collegamento

You can scale pods based on CPU metrics. This trigger uses cluster metrics as the source for metrics.

The custom metrics autoscaler scales the pods associated with an object to maintain the CPU usage that you specify. The autoscaler increases or decreases the number of replicas between the minimum and maximum numbers to maintain the specified CPU utilization across all pods. The memory trigger considers the memory utilization of the entire pod. If the pod has multiple containers, the memory trigger considers the total memory utilization of all containers in the pod.

Note

This trigger cannot be used with the
```
ScaledJob
```
custom resource.
When using a memory trigger to scale an object, the object does not scale to
```
0
```
, even if you are using multiple triggers.

Example scaled object with a CPU target

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: cpu

1


    metricType: Utilization

2


    metadata:
      value: '60'

3


  minReplicaCount: 1

4

Specifies CPU as the trigger type.

Specifies the type of metric to use, either Utilization or AverageValue.

Specifies the value that triggers scaling. Must be specified as a quoted string value.

When using
```
Utilization
```
, the target value is the average of the resource metrics across all relevant pods, represented as a percentage of the requested value of the resource for the pods.
When using
```
AverageValue
```
, the target value is the average of the metrics across all relevant pods.

Specifies the minimum number of replicas when scaling down. For a CPU trigger, enter a value of 1 or greater, because the HPA cannot scale to zero if you are using only CPU metrics.

3.4.3. Understanding the memory trigger
Copia collegamento

You can scale pods based on memory metrics. This trigger uses cluster metrics as the source for metrics.

The custom metrics autoscaler scales the pods associated with an object to maintain the average memory usage that you specify. The autoscaler increases and decreases the number of replicas between the minimum and maximum numbers to maintain the specified memory utilization across all pods. The memory trigger considers the memory utilization of entire pod. If the pod has multiple containers, the memory utilization is the sum of all of the containers.

Note

This trigger cannot be used with the
```
ScaledJob
```
custom resource.
When using a memory trigger to scale an object, the object does not scale to
```
0
```
, even if you are using multiple triggers.

Example scaled object with a memory target

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: memory

1


    metricType: Utilization

2


    metadata:
      value: '60'

3


      containerName: api

4

Specifies memory as the trigger type.

Specifies the type of metric to use, either Utilization or AverageValue.

Specifies the value that triggers scaling. Must be specified as a quoted string value.

When using
```
Utilization
```
, the target value is the average of the resource metrics across all relevant pods, represented as a percentage of the requested value of the resource for the pods.
When using
```
AverageValue
```
, the target value is the average of the metrics across all relevant pods.

Optional: Specifies an individual container to scale, based on the memory utilization of only that container, rather than the entire pod. In this example, only the container named api is to be scaled.

3.4.4. Understanding the Kafka trigger
Copia collegamento

You can scale pods based on an Apache Kafka topic or other services that support the Kafka protocol. The custom metrics autoscaler does not scale higher than the number of Kafka partitions, unless you set the

allowIdleConsumers

parameter to

true

in the scaled object or scaled job.

Note

If the number of consumer groups exceeds the number of partitions in a topic, the extra consumer groups remain idle. To avoid this, by default the number of replicas does not exceed:

The number of partitions on a topic, if a topic is specified
The number of partitions of all topics in the consumer group, if no topic is specified
The
```
maxReplicaCount
```
specified in scaled object or scaled job CR

You can use the

allowIdleConsumers

parameter to disable these default behaviors.

Example scaled object with a Kafka target

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
# ...
  triggers:
  - type: kafka

1


    metadata:
      topic: my-topic

2


      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092

3


      consumerGroup: my-group

4


      lagThreshold: '10'

5


      activationLagThreshold: '5'

6


      offsetResetPolicy: latest

7


      allowIdleConsumers: true

8


      scaleToZeroOnInvalidOffset: false

9


      excludePersistentLag: false

10


      version: '1.0.0'

11


      partitionLimitation: '1,2,10-20,31'

12

Specifies Kafka as the trigger type.

Specifies the name of the Kafka topic on which Kafka is processing the offset lag.

Specifies a comma-separated list of Kafka brokers to connect to.