SupportConsoleDéveloppeursCommencer un essaiContact

4.2. Mise à l'échelle automatique

4.2.1. Mise à l'échelle automatique

Knative Serving fournit une mise à l'échelle automatique, ou autoscaling, pour les applications afin de répondre à la demande entrante. Par exemple, si une application ne reçoit aucun trafic et que l'option scale-to-zero est activée, Knative Serving réduit l'application à zéro réplicas. Si l'option scale-to-zero est désactivée, l'application est réduite au nombre minimum de répliques configuré pour les applications sur le cluster. Les répliques peuvent également être mises à l'échelle pour répondre à la demande si le trafic de l'application augmente.

Les paramètres de mise à l'échelle automatique des services Knative peuvent être des paramètres globaux configurés par les administrateurs du cluster, ou des paramètres par révision configurés pour des services individuels.

Vous pouvez modifier les paramètres par révision de vos services en utilisant la console web d'OpenShift Container Platform, en modifiant le fichier YAML de votre service, ou en utilisant le CLI Knative (kn).

Note

Toutes les limites ou tous les objectifs que vous définissez pour un service sont mesurés par rapport à une instance unique de votre application. Par exemple, la définition de l'annotation target sur 50 configure l'autoscaler pour qu'il mette l'application à l'échelle de manière à ce que chaque révision traite 50 demandes à la fois.

4.2.2. Limites d'échelle

Les limites d'échelle déterminent les nombres minimum et maximum de répliques pouvant servir une application à un moment donné. Vous pouvez définir des limites d'échelle pour une application afin d'éviter les démarrages à froid ou de contrôler les coûts informatiques.

4.2.2.1. Limites minimales de l'échelle

Le nombre minimum de répliques pouvant servir une application est déterminé par l'annotation min-scale. Si la mise à zéro n'est pas activée, la valeur de min-scale est par défaut 1.

La valeur min-scale est remplacée par défaut par des répliques 0 si les conditions suivantes sont remplies :

  • L'annotation min-scale n'est pas définie
  • La mise à l'échelle à zéro est activée
  • La classe KPA est utilisée

Exemple de spécification de service avec l'annotation min-scale 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
...

4.2.2.1.1. Définir l'annotation min-scale en utilisant le CLI Knative

L'utilisation de l'interface de programmation Knative (kn) pour définir l'annotation min-scale offre une interface utilisateur plus rationnelle et plus intuitive que la modification directe des fichiers YAML. Vous pouvez utiliser la commande kn service avec l'indicateur --scale-min pour créer ou modifier la valeur min-scale pour un service.

Conditions préalables

  • Knative Serving est installé sur le cluster.
  • Vous avez installé le CLI Knative (kn).

Procédure

  • Définissez le nombre minimum de répliques pour le service en utilisant l'option --scale-min: 

    $ kn service create <service_name> --image <image_uri> --scale-min <integer>

    Example command

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-min 2

4.2.2.2. Limites maximales de l'échelle

Le nombre maximum de répliques pouvant servir une application est déterminé par l'annotation max-scale. Si l'annotation max-scale n'est pas définie, il n'y a pas de limite supérieure pour le nombre de répliques créées.

Exemple de spécification de service avec l'annotation max-scale 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "10"
...

4.2.2.2.1. Définir l'annotation max-scale en utilisant le CLI Knative

L'utilisation de l'interface de programmation Knative (kn) pour définir l'annotation max-scale offre une interface utilisateur plus rationnelle et plus intuitive que la modification directe des fichiers YAML. Vous pouvez utiliser la commande kn service avec l'indicateur --scale-max pour créer ou modifier la valeur max-scale pour un service.

Conditions préalables

  • Knative Serving est installé sur le cluster.
  • Vous avez installé le CLI Knative (kn).

Procédure

  • Définissez le nombre maximum de répliques pour le service en utilisant l'option --scale-max: 

    $ kn service create <service_name> --image <image_uri> --scale-max <integer>

    Example command

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-max 10

4.2.3. Concurrence

La concurence détermine le nombre de requêtes simultanées qui peuvent être traitées par chaque réplique d'une application à un moment donné. La simultanéité peut être configurée comme soft limit ou hard limit:

  • Une limite souple est une limite de demande ciblée, plutôt qu'une limite strictement appliquée. Par exemple, en cas d'augmentation soudaine du trafic, la limite souple peut être dépassée.

  • Une limite stricte est une limite supérieure de demandes strictement appliquée. Si la concurrence atteint la limite supérieure, les demandes excédentaires sont mises en mémoire tampon et doivent attendre qu'il y ait suffisamment de capacité libre pour les exécuter.

    Important

    L'utilisation d'une configuration de limite stricte n'est recommandée que s'il existe un cas d'utilisation clair pour votre application. Le fait de spécifier une limite basse et stricte peut avoir un impact négatif sur le débit et la latence d'une application, et peut provoquer des démarrages à froid.

L'ajout d'une cible souple et d'une limite stricte signifie que l'autoscaler vise la cible souple du nombre de requêtes simultanées, mais impose une limite stricte de la valeur de la limite stricte pour le nombre maximum de requêtes.

Si la valeur de la limite dure est inférieure à la valeur de la limite souple, la valeur de la limite souple est réduite, car il n'est pas nécessaire de cibler plus de demandes que le nombre qui peut réellement être traité.

4.2.3.1. Configuration d'une cible de concurrence douce

Une limite souple est une limite de demande ciblée, plutôt qu'une limite strictement appliquée. Par exemple, s'il y a une explosion soudaine du trafic, la cible de la limite souple peut être dépassée. Vous pouvez spécifier un objectif de concurrence souple pour votre service Knative en définissant l'annotation autoscaling.knative.dev/target dans la spécification, ou en utilisant la commande kn service avec les drapeaux corrects.

Procédure

  • Facultatif : Définissez l'annotation autoscaling.knative.dev/target pour votre service Knative dans la spécification de la ressource personnalisée Service:

    Exemple de cahier des charges

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "200"

  • Facultatif : Utilisez la commande kn service pour spécifier l'indicateur --concurrency-target: 

    $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

    Exemple de commande pour créer un service avec un objectif de concurrence de 50 requêtes

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50

4.2.3.2. Configuration d'une limite de concurrence stricte

Une limite de concurrence stricte est une limite supérieure de demandes strictement appliquée. Si la concurrence atteint la limite dure, les demandes excédentaires sont mises en mémoire tampon et doivent attendre qu'il y ait suffisamment de capacité libre pour les exécuter. Vous pouvez spécifier une limite dure de concurrence pour votre service Knative en modifiant la spécification containerConcurrency, ou en utilisant la commande kn service avec les drapeaux corrects.

Procédure

  • Facultatif : Définissez la spécification containerConcurrency pour votre service Knative dans la spécification de la ressource personnalisée Service:

    Exemple de cahier des charges

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 50

    La valeur par défaut est 0, ce qui signifie qu'il n'y a pas de limite au nombre de requêtes simultanées autorisées dans une réplique du service à la fois.

    Une valeur supérieure à 0 spécifie le nombre exact de requêtes autorisées à circuler dans une réplique du service à la fois. Dans cet exemple, la limite de simultanéité est fixée à 50 requêtes.

  • Facultatif : Utilisez la commande kn service pour spécifier l'indicateur --concurrency-limit: 

    $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

    Exemple de commande pour créer un service avec une limite de concurrence de 50 requêtes

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50

4.2.3.3. Utilisation de l'objectif de simultanéité

Cette valeur indique le pourcentage de la limite de concurrence qui est effectivement ciblé par l'autoscaler. Il s'agit également de spécifier la valeur hotness à laquelle un réplica s'exécute, ce qui permet à l'autoscaler d'augmenter sa capacité avant que la limite définie ne soit atteinte.

Par exemple, si la valeur containerConcurrency est fixée à 10 et la valeur target-utilization-percentage à 70 %, l'autoscaler crée une nouvelle réplique lorsque le nombre moyen de requêtes simultanées dans toutes les répliques existantes atteint 7. Les demandes numérotées de 7 à 10 sont toujours envoyées aux répliques existantes, mais des répliques supplémentaires sont démarrées en prévision d'un besoin lorsque la valeur containerConcurrency est atteinte.

Exemple de service configuré à l'aide de l'annotation target-utilization-percentage

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
...

4.2.4. Échelle zéro

Knative Serving permet une mise à l'échelle automatique, ou autoscaling, des applications pour répondre à la demande entrante.

4.2.4.1. Permettre le passage à l'échelle zéro

Vous pouvez utiliser la spécification enable-scale-to-zero pour activer ou désactiver globalement le passage à l'échelle zéro pour les applications sur le cluster.

Conditions préalables

  • Vous avez installé OpenShift Serverless Operator et Knative Serving sur votre cluster.
  • Vous avez des droits d'administrateur de cluster.
  • Vous utilisez le Knative Pod Autoscaler par défaut. La fonction de mise à zéro n'est pas disponible si vous utilisez le Kubernetes Horizontal Pod Autoscaler.

Procédure

  • Modifier la spécification enable-scale-to-zero dans la ressource personnalisée (CR) KnativeServing:

    Exemple KnativeServing CR

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    autoscaler:
      enable-scale-to-zero: "false" 1

    1
    La spécification enable-scale-to-zero peut être "true" ou "false". Si elle vaut true, la fonction scale-to-zero est activée. S'il est défini sur false, les applications sont réduites à la valeur configurée minimum scale bound. La valeur par défaut est "true".

4.2.4.2. Configuration du délai de grâce scale-to-zero

Knative Serving fournit une mise à l'échelle automatique jusqu'à zéro pods pour les applications. Vous pouvez utiliser la spécification scale-to-zero-grace-period pour définir une limite de temps supérieure pendant laquelle Knative attend que le mécanisme de mise à l'échelle vers zéro soit en place avant que la dernière réplique d'une application soit supprimée.

Conditions préalables

  • Vous avez installé OpenShift Serverless Operator et Knative Serving sur votre cluster.
  • Vous avez des droits d'administrateur de cluster.
  • Vous utilisez le Knative Pod Autoscaler par défaut. La fonctionnalité scale-to-zero n'est pas disponible si vous utilisez le Kubernetes Horizontal Pod Autoscaler.

Procédure

  • Modifier la spécification scale-to-zero-grace-period dans la ressource personnalisée (CR) KnativeServing:

    Exemple KnativeServing CR

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    autoscaler:
      scale-to-zero-grace-period: "30s" 1

    1
    Durée du délai de grâce en secondes. La valeur par défaut est de 30 secondes.
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.

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 leBlog 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.

© 2024 Red Hat, Inc.