Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

3.4. Comprendre les déclencheurs automatiques des mesures personnalisées

Les déclencheurs, également connus sous le nom de balanceurs, fournissent les métriques que le Custom Metrics Autoscaler Operator utilise pour mettre à l’échelle vos pods.

L’autoscaler de mesures personnalisées prend actuellement en charge les déclencheurs Prometheus, CPU, mémoire, Apache Kafka et cron.

Dans les sections qui suivent, vous utilisez une ressource personnalisée ScaledObject ou ScaledJob pour configurer des déclencheurs pour des objets spécifiques.

Il est possible de configurer une autorité de certification à utiliser avec vos objets mis à l’échelle ou pour tous les planificateurs du cluster.

3.4.1. Comprendre le déclencheur Prométhée
Copier lien

Les pods peuvent être mis à l’échelle en fonction des métriques Prometheus, qui peuvent utiliser le Red Hat OpenShift Service installé sur la surveillance AWS ou un serveur Prometheus externe comme source de métriques. Consultez "Configurer les métriques personnalisées autoscaler pour utiliser Red Hat OpenShift Service sur la surveillance AWS" pour obtenir des informations sur les configurations requises pour utiliser le service Red Hat OpenShift sur la surveillance AWS comme source de métriques.

Note

Lorsque Prometheus collecte des métriques à partir de l’application que l’échelle automatique des métriques personnalisées s’évolue, ne définissez pas les répliques minimales à 0 dans la ressource personnalisée. En l’absence de pods d’application, l’autoscaler de métriques personnalisées n’a pas de métriques à mettre à l’échelle.

Exemple d’objet mis à l’échelle avec une cible Prometheus

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

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

      namespace: kedatest
3 

      metricName: http_requests_total
4 

      threshold: '5'
5 

      query: sum(rate(http_requests_total{job="test-app"}[1m]))
6 

      authModes: basic
7 

      cortexOrgID: my-org
8 

      ignoreNullValues: "false"
9 

      unsafeSsl: "false"
10
Copy to Clipboard Toggle word wrap

1
Indique Prometheus comme type de déclencheur.
2
Indique l’adresse du serveur Prometheus. Cet exemple utilise Red Hat OpenShift Service sur la surveillance AWS.
3
Facultatif : Spécifie l’espace de noms de l’objet que vous souhaitez mettre à l’échelle. Ce paramètre est obligatoire si vous utilisez Red Hat OpenShift Service sur la surveillance AWS comme source pour les métriques.
4
Indique le nom pour identifier la métrique dans l’API externe.metrics.k8s.io. Lorsque vous utilisez plus d’un déclencheur, tous les noms métriques doivent être uniques.
5
Indique la valeur qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée.
6
Indique la requête Prometheus à utiliser.
7
Indique la méthode d’authentification à utiliser. Les échelles Prometheus prennent en charge l’authentification au porteur (porteur), l’authentification de base (basique) ou l’authentification TLS (tls). Comme indiqué dans une section suivante, vous configurez les paramètres d’authentification spécifiques dans une authentification de déclencheur. Au besoin, vous pouvez également utiliser un secret.
8
Facultatif : Passe l’en-tête X-Scope-OrgID à un stockage multi-locataires Cortex ou Mimir pour Prometheus. Ce paramètre n’est requis qu’avec le stockage Prometheus multi-locataires, pour indiquer quelles données Prometheus doit retourner.
9
Facultatif : Spécifie comment le déclencheur doit procéder si la cible Prometheus est perdue.
  • Dans l’affirmative, le déclencheur continue de fonctionner si la cible Prometheus est perdue. C’est le comportement par défaut.
  • En cas de faux, le déclencheur renvoie une erreur si la cible Prometheus est perdue.
10
Facultatif: Spécifie si la vérification du certificat doit être ignorée. À titre d’exemple, vous pouvez sauter la vérification si vous êtes en cours d’exécution dans un environnement de test et en utilisant des certificats autosignés au point de terminaison Prometheus.
  • En cas de faux, la vérification du certificat est effectuée. C’est le comportement par défaut.

  • Dans l’affirmative, la vérification du certificat n’est pas effectuée.

    Important

    Il n’est pas recommandé de sauter le chèque.

Le service Red Hat OpenShift installé sur AWS Prometheus peut être utilisé comme source pour les métriques utilisées par l’autoscaleur de mesures personnalisées. Cependant, il y a quelques configurations supplémentaires que vous devez effectuer.

Afin que vos objets mis à l’échelle puissent lire le service Red Hat OpenShift sur les métriques AWS Prometheus, vous devez utiliser une authentification de déclencheur ou une authentification de déclencheur de cluster afin de fournir les informations d’authentification requises. La procédure suivante diffère selon la méthode d’authentification de déclenchement que vous utilisez. En savoir plus sur les authentifications de déclenchement, voir « Comprendre les authentifications automatiques des métriques personnalisées ».

Note

Ces étapes ne sont pas nécessaires pour une source externe de Prometheus.

Comme décrit dans cette section, vous devez effectuer les tâches suivantes:

  • Créer un compte de service.
  • Créez un secret qui génère un jeton pour le compte de service.
  • Créez l’authentification de déclencheur.
  • Créer un rôle.
  • Ajoutez ce rôle au compte de service.
  • Faites référence au jeton dans l’objet d’authentification de déclenchement utilisé par Prometheus.

Conditions préalables

  • Le service OpenShift Red Hat sur la surveillance AWS doit être installé.
  • La surveillance des charges de travail définies par l’utilisateur doit être activée dans Red Hat OpenShift Service sur la surveillance AWS, comme décrit dans la section Création d’une carte de configuration de la charge de travail définie par l’utilisateur.
  • Le Custom Metrics Autoscaler Operator doit être installé.

Procédure

  1. Changement au projet approprié: 

    $ oc project <project_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    Indique l’un des projets suivants:
    • Lorsque vous utilisez une authentification de déclencheur, spécifiez le projet avec l’objet que vous souhaitez mettre à l’échelle.
    • Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez le projet openshift-keda.

  2. Créez un compte de service et un jeton, si votre cluster n’en a pas:

    1. Créer un objet de compte de service en utilisant la commande suivante: 

      $ oc create serviceaccount thanos
      1
      Copy to Clipboard Toggle word wrap
      1
      Indique le nom du compte de service.

    2. Créez un YAML secret pour générer un jeton de compte de service: 

      apiVersion: v1
kind: Secret
metadata:
  name: thanos-token
  annotations:
    kubernetes.io/service-account.name: thanos
      1 
      
type: kubernetes.io/service-account-token
      Copy to Clipboard Toggle word wrap
      1
      Indique le nom du compte de service.

    3. Créez l’objet secret en utilisant la commande suivante: 

      $ oc create -f <file_name>.yaml
      Copy to Clipboard Toggle word wrap

    4. À l’aide de la commande suivante pour localiser le jeton attribué au compte de service: 

      $ oc describe serviceaccount thanos
      1
      Copy to Clipboard Toggle word wrap
      1
      Indique le nom du compte de service.

      Exemple de sortie

      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>
      Copy to Clipboard Toggle word wrap

      1
      Utilisez ce jeton dans l’authentification de déclencheur.

  3. Créer une authentification de déclenchement avec le jeton de compte de service:

    1. Créez un fichier YAML similaire à ce qui suit: 

      apiVersion: keda.sh/v1alpha1
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
      Copy to Clipboard Toggle word wrap
      1
      Indique l’une des méthodes d’authentification de déclenchement suivantes:
      • Lorsque vous utilisez une authentification de déclencheur, spécifiez TriggerAuthentication. Cet exemple configure une authentification de déclenchement.
      • Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez ClusterTriggerAuthentication.
      2
      Indique que cet objet utilise un secret pour l’autorisation.
      3
      Indique le paramètre d’authentification à fournir en utilisant le jeton.
      4
      Indique le nom du jeton à utiliser.
      5
      Indique la clé dans le jeton à utiliser avec le paramètre spécifié.

    2. Créer l’objet CR: 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

  4. Créer un rôle pour lire les métriques Thanos:

    1. Créez un fichier YAML avec les paramètres suivants: 

      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
      Copy to Clipboard Toggle word wrap

    2. Créer l’objet CR: 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

  5. Créer une liaison de rôle pour lire les métriques Thanos:

    1. Créez un fichier YAML similaire à ce qui suit: 

      apiVersion: rbac.authorization.k8s.io/v1
kind: <binding_type>
      1 
      
metadata:
  name: thanos-metrics-reader
      2 
      
  namespace: my-project
      3 
      
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: thanos-metrics-reader
subjects:
- kind: ServiceAccount
  name: thanos
      4 
      
  namespace: <namespace_name>
      5
      Copy to Clipboard Toggle word wrap
      1
      Indique l’un des types d’objets suivants:
      • Lorsque vous utilisez une authentification de déclencheur, spécifiez RoleBinding.
      • Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez ClusterRoleBinding.
      2
      Indique le nom du rôle que vous avez créé.
      3
      Indique l’un des projets suivants:
      • Lorsque vous utilisez une authentification de déclencheur, spécifiez le projet avec l’objet que vous souhaitez mettre à l’échelle.
      • Lorsque vous utilisez une authentification de déclencheur de cluster, spécifiez le projet openshift-keda.
      4
      Indique le nom du compte de service pour se lier au rôle.
      5
      Indique le projet où vous avez précédemment créé le compte de service.

    2. Créer l’objet CR: 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

Comme décrit dans « Comprendre comment ajouter des métriques personnalisées », vous pouvez maintenant déployer un objet à l’échelle ou une tâche mise à l’échelle pour activer l’autoscaling de votre application. Afin d’utiliser Red Hat OpenShift Service sur la surveillance AWS comme source, dans le déclencheur ou dans l’échelle, vous devez inclure les paramètres suivants:

  • triggers.type doit être promisheus
  • triggers.metadata.serverAdresse doit être https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
  • triggers.metadata.authModes doivent être porteurs
  • triggers.metadata.namespace doit être réglé sur l’espace de noms de l’objet à l’échelle
  • triggers.authenticationRef doit pointer vers la ressource d’authentification de déclencheur spécifiée à l’étape précédente

3.4.2. Comprendre le déclencheur CPU
Copier lien

Les pods peuvent être mis à l’échelle en fonction des métriques CPU. Ce déclencheur utilise les métriques de cluster comme source pour les métriques.

Les mesures personnalisées autoscaler met à l’échelle les pods associés à un objet pour maintenir l’utilisation du CPU que vous spécifiez. L’autoscaler augmente ou diminue le nombre de répliques entre les nombres minimum et maximum pour maintenir l’utilisation spécifiée du CPU dans toutes les gousses. Le déclencheur de mémoire tient compte de l’utilisation de la mémoire de l’ensemble de la gousse. Lorsque la gousse a plusieurs conteneurs, le déclencheur de mémoire prend en compte l’utilisation totale de la mémoire de tous les conteneurs dans le pod.

Note
  • Ce déclencheur ne peut pas être utilisé avec la ressource personnalisée ScaledJob.
  • Lors de l’utilisation d’un déclencheur de mémoire pour mettre à l’échelle un objet, l’objet ne se met pas à l’échelle à 0, même si vous utilisez plusieurs déclencheurs.

Exemple d’objet mis à l’échelle avec une cible CPU

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
Copy to Clipboard Toggle word wrap

1
Indique CPU comme type de déclencheur.
2
Indique le type de métrique à utiliser, soit l’utilisation ou la valeur moyenne.
3
Indique la valeur qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée.
  • Lors de l’utilisation, la valeur cible est la moyenne des métriques de ressources pour tous les pods pertinents, représentée en pourcentage de la valeur demandée de la ressource pour les pods.
  • Lors de l’utilisation de la valeur moyenne, la valeur cible est la moyenne des métriques de tous les pods pertinents.
4
Indique le nombre minimum de répliques lors de la mise à l’échelle. Dans le cas d’un déclencheur CPU, entrez une valeur de 1 ou plus, car le HPA ne peut pas atteindre zéro si vous utilisez uniquement des métriques CPU.

3.4.3. Comprendre le déclencheur de la mémoire
Copier lien

Les pods peuvent être mis à l’échelle en fonction des métriques de mémoire. Ce déclencheur utilise les métriques de cluster comme source pour les métriques.

Les mesures personnalisées autoscaler met à l’échelle les pods associés à un objet pour maintenir l’utilisation moyenne de la mémoire que vous spécifiez. L’autoscaler augmente et diminue le nombre de répliques entre les nombres minimum et maximum pour maintenir l’utilisation de la mémoire spécifiée dans toutes les gousses. Le déclencheur de mémoire considère l’utilisation de la mémoire de la gousse entière. Lorsque la gousse a plusieurs conteneurs, l’utilisation de la mémoire est la somme de tous les conteneurs.

Note
  • Ce déclencheur ne peut pas être utilisé avec la ressource personnalisée ScaledJob.
  • Lors de l’utilisation d’un déclencheur de mémoire pour mettre à l’échelle un objet, l’objet ne se met pas à l’échelle à 0, même si vous utilisez plusieurs déclencheurs.

Exemple d’objet mis à l’échelle avec une cible mémoire

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
Copy to Clipboard Toggle word wrap

1
Indique la mémoire comme type de déclenchement.
2
Indique le type de métrique à utiliser, soit l’utilisation ou la valeur moyenne.
3
Indique la valeur qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée.
  • Lors de l’utilisation, la valeur cible est la moyenne des métriques de ressources pour tous les pods pertinents, représentée en pourcentage de la valeur demandée de la ressource pour les pods.
  • Lors de l’utilisation de la valeur moyenne, la valeur cible est la moyenne des métriques de tous les pods pertinents.
4
Facultatif: Spécifie un conteneur individuel à l’échelle, en fonction de l’utilisation de la mémoire seulement de ce conteneur, plutôt que de l’ensemble de la gousse. Dans cet exemple, seul le conteneur nommé api doit être mis à l’échelle.

3.4.4. Comprendre le déclencheur Kafka
Copier lien

Les pods peuvent être mis à l’échelle en fonction d’un sujet Apache Kafka ou d’autres services prenant en charge le protocole Kafka. L’échelle automatique des métriques personnalisées ne dépasse pas le nombre de partitions Kafka, à moins que vous n’ayez défini le paramètre allowIdleConsumers sur true dans l’objet mis à l’échelle ou le travail mis à l’échelle.

Note

Lorsque le nombre de groupes de consommateurs dépasse le nombre de partitions dans un sujet, les groupes de consommateurs supplémentaires restent inactifs. Afin d’éviter cela, le nombre de répliques par défaut ne dépasse pas:

  • Le nombre de partitions sur un sujet, si un sujet est spécifié
  • Le nombre de partitions de tous les sujets du groupe de consommateurs, si aucun sujet n’est spécifié
  • Le maxReplicaCount spécifié dans l’objet mis à l’échelle ou le travail mis à l’échelle CR

Le paramètre allowIdleConsumers permet de désactiver ces comportements par défaut.

Exemple d’objet mis à l’échelle avec une cible Kafka

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 

      tls: enable
13
Copy to Clipboard Toggle word wrap

1
Indique Kafka comme type de déclencheur.
2
Indique le nom du sujet Kafka sur lequel Kafka traite le décalage.
3
Indique une liste séparée par virgule des courtiers Kafka auxquels se connecter.
4
Indique le nom du groupe de consommateurs Kafka utilisé pour vérifier le décalage sur le sujet et traiter le décalage associé.
5
Facultatif : Spécifie la valeur cible moyenne qui déclenche la mise à l’échelle. Doit être spécifié comme une valeur de chaîne citée. La valeur par défaut est 5.
6
Facultatif : Spécifie la valeur cible pour la phase d’activation. Doit être spécifié comme une valeur de chaîne citée.
7
Facultatif: Spécifie la politique de réinitialisation de l’offset Kafka pour le consommateur Kafka. Les valeurs disponibles sont les suivantes: les plus récentes et les plus anciennes. La valeur par défaut est la dernière.
8
Facultatif : Spécifie si le nombre de répliques Kafka peut dépasser le nombre de partitions sur un sujet.
  • Dans l’affirmative, le nombre de répliques Kafka peut dépasser le nombre de partitions sur un sujet. Cela permet aux consommateurs de Kafka oisifs.
  • En cas de faux, le nombre de répliques Kafka ne peut pas dépasser le nombre de partitions sur un sujet. C’est la valeur par défaut.
9
Indique comment le déclencheur se comporte lorsqu’une partition Kafka n’a pas de décalage valide.
  • Dans l’affirmative, les consommateurs sont réduits à zéro pour cette partition.
  • En cas de faux, l’échelle garde un seul consommateur pour cette partition. C’est la valeur par défaut.
10
Facultatif : Spécifie si le déclencheur inclut ou exclut le décalage de partition pour les partitions dont le décalage courant est le même que le décalage courant du cycle de sondage précédent.
  • Dans l’affirmative, l’échelle exclut le décalage de partition dans ces partitions.
  • En cas de faux, le déclencheur inclut tous les décalages du consommateur dans toutes les partitions. C’est la valeur par défaut.
11
Facultatif: Spécifie la version de vos courtiers Kafka. Doit être spécifié comme une valeur de chaîne citée. La valeur par défaut est 1.0.0.
12
Facultatif: Spécifie une liste séparée par virgule d’IDs de partition pour étendre la mise à l’échelle. Lorsqu’il est défini, seuls les identifiants listés sont pris en compte lors du calcul du décalage. Doit être spécifié comme une valeur de chaîne citée. La valeur par défaut est de prendre en compte toutes les partitions.
13
Facultatif : Spécifie s’il faut utiliser l’authentification client TSL pour Kafka. La valeur par défaut est désactivée. Informations sur la configuration de TLS, voir « Comprendre les authentifications automatiques des métriques personnalisées ».

3.4.5. Comprendre le déclencheur Cron
Copier lien

Les pods peuvent être mis à l’échelle en fonction d’une plage de temps.

Lorsque la plage de temps démarre, les métriques personnalisées autoscalent les pods associés à un objet à partir du nombre minimum configuré de pods au nombre spécifié de gousses souhaitées. À la fin de la plage de temps, les pods sont réduits au minimum configuré. La période de temps doit être configurée au format cron.

L’exemple suivant met à l’échelle les pods associés à cet objet mis à l’échelle de 0 à 100 de 6h00 à 18h30 heure normale de l’Inde.

Exemple d’objet mis à l’échelle avec un déclencheur Cron

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    name: my-deployment
  minReplicaCount: 0
1 

  maxReplicaCount: 100
2 

  cooldownPeriod: 300
  triggers:
  - type: cron
3 

    metadata:
      timezone: Asia/Kolkata
4 

      start: "0 6 * * *"
5 

      end: "30 18 * * *"
6 

      desiredReplicas: "100"
7
Copy to Clipboard Toggle word wrap

1
Indique le nombre minimum de gousses à réduire à la fin du délai.
2
Indique le nombre maximal de répliques lors de la mise à l’échelle. Cette valeur devrait être la même que celle souhaitéeReplicas. La valeur par défaut est 100.
3
Indique un déclencheur Cron.
4
Indique le fuseau horaire pour la période de temps. Cette valeur doit provenir de la base de données du fuseau horaire IANA.
5
Indique le début de la période de temps.
6
Indique la fin du délai.
7
Indique le nombre de gousses à mettre à l’échelle entre le début et la fin du délai. Cette valeur devrait être la même que maxReplicaCount.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat