Définir des règles de mise à l’échelle dans Azure Container Apps

Article
02/22/2024

Azure Container Apps gère la mise à l’échelle horizontale automatique en utilisant un ensemble de règles de mise à l’échelle déclaratives. À mesure qu’une révision d’application conteneur est mise à l’échelle, de nouvelles instances de la révision sont créées à la demande. Ces instances sont appelées réplicas.

L’ajout ou la modification de règles de mise à l’échelle crée une nouvelle révision de votre application conteneur. Une révision est un instantané immuable de votre application conteneur. Consultez les types de changements de révision pour passer en revue les types de changements qui déclenchent une nouvelle révision.

Les travaux Container Apps pilotés par les événements utilisent des règles de mise à l’échelle pour déclencher des exécutions en fonction des événements.

Définition de mise à l’échelle

La mise à l’échelle est définie par la combinaison de limites, de règles et de comportement.

Les limites correspondent au nombre minimal et maximal possible de réplicas par révision, à mesure que votre application conteneur est mise à l’échelle.

Limite de la mise à l’échelle	Valeur par défaut	Valeur min	Valeur max
Nombre minimal de réplicas par révision	0	0	Les réplicas maximum configurables sont au nombre de 300 dans le portail Azure et 1 000 dans Azure CLI.
Nombre maximal de réplicas par révision	10	1	Les réplicas maximum configurables sont au nombre de 300 dans le portail Azure et 1 000 dans Azure CLI.

Pour plus d’informations, consultez Quotas pour Azure Container Apps.

Les règles sont les critères utilisés par Container Apps pour décider quand ajouter ou supprimer des réplicas.

Les règles de mise à l’échelle sont implémentées au format HTTP, TCP ou personnalisé.
Le comportement correspond à la façon dont les règles et les limites sont combinées pour déterminer les décisions de mise à l’échelle au fil du temps.

Le comportement de mise à l’échelle explique la façon dont les décisions de mise à l’échelle sont calculées.

Lorsque vous définissez vos règles de mise à l’échelle, gardez à l’esprit les éléments suivants :

Les frais d’utilisation ne vous sont pas facturés si votre application de conteneur est mise à l’échelle à zéro.
Les réplicas qui ne sont pas en cours de traitement, mais qui restent en mémoire peuvent être facturés à un taux « d’inactivité » moins élevé. Pour plus d'informations, consultez Facturation.
Si vous souhaitez vous assurer qu’une instance de votre révision est toujours en cours d’exécution, définissez le nombre minimal de réplicas sur 1 ou plus.

Règles de mise à l’échelle

La mise à l’échelle est pilotée par trois catégories de déclencheurs différentes :

HTTP : en fonction du nombre de requêtes HTTP simultanées adressées à votre révision.
TCP : en fonction du nombre de connexions TCP simultanées adressées à votre révision.
Personnalisé : en fonction du processeur, de la mémoire ou des sources de données pilotées par les événements prises en charge, par exemple :
- Azure Service Bus
- Hubs d'événements Azure
- Apache Kafka
- Redis

Si vous définissez plusieurs règles de mise à l’échelle, l’application conteneur commence à effectuer une mise à l’échelle une fois que la première condition d’une règle est remplie.

HTTP

Avec une règle de mise à l’échelle HTTP, vous avez le contrôle sur le seuil des requêtes HTTP simultanées qui détermine la façon dont votre révision d’application conteneur est mise à l’échelle. Toutes les 15 secondes, le nombre de requêtes simultanées est calculé en tant que nombre de requêtes au cours des 15 dernières secondes divisé par 15. Les travaux Container Apps ne prennent pas en charge les règles de mise à l’échelle HTTP.

Dans l’exemple suivant, la révision effectue un scale-out jusqu’à cinq réplicas et peut effectué un scale-in jusqu’à zéro. La propriété de mise à l’échelle est définie sur 100 requêtes simultanées par seconde.

Exemple

La section http définit une règle de mise à l’échelle HTTP.

Propriété de mise à l’échelle	Description	Valeur par défaut	Valeur min	Valeur max
`concurrentRequests`	Quand le nombre de requêtes HTTP dépasse cette valeur, un autre réplica est ajouté. Les réplicas continuent d’être ajoutés au pool jusqu’à ce que la quantité `maxReplicas` soit atteinte.	10	1	n/a

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Remarque

Affectez à la propriété properties.configuration.activeRevisionsMode de l’application conteneur la valeur single, quand vous utilisez des règles de mise à l’échelle d’événements non HTTP.

Définissez une règle de mise à l’échelle HTTP à l’aide du paramètre --scale-rule-http-concurrency dans les commandes create ou update.

Paramètre CLI	Description	Valeur par défaut	Valeur min	Valeur max
`--scale-rule-http-concurrency`	Quand le nombre de requêtes HTTP simultanées dépasse cette valeur, un autre réplica est ajouté. Les réplicas continuent d’être ajoutés au pool jusqu’à ce que la quantité `max-replicas` soit atteinte.	10	1	n/a

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --scale-rule-name azure-http-rule \
  --scale-rule-type http \
  --scale-rule-http-concurrency 100

Accédez à votre application conteneur dans le portail Azure
Sélectionnez Mettre à l’échelle.
Sélectionnez Modifier et déployer.
Sélectionnez l’onglet Mettre à l’échelle.
Sélectionnez la plage de réplicas minimale et maximale.
Sélectionnez Ajouter.
Dans la zone Nom de la règle, entrez un nom de règle.
Dans la liste déroulante Type, sélectionnez Mise à l’échelle HTTP.
Dans la zone Requêtes simultanées, entrez le nombre de requêtes simultanées souhaité pour votre application conteneur.

TCP

Avec une règle de mise à l’échelle TCP, vous avez un contrôle sur le seuil des connexions TCP simultanées qui détermine la façon dont votre application est mise à l’échelle. Toutes les 15 secondes, le nombre de connexions simultanées est calculé en tant que nombre de connexions au cours des 15 dernières secondes divisé par 15. Les travaux Container Apps ne prennent pas en charge les règles de mise à l’échelle TCP.

Dans l’exemple suivant, la révision de l’application conteneur effectue un scale-out jusqu’à cinq réplicas et peut effectuer un scale-in jusqu’à zéro. Le seuil de mise à l’échelle est défini sur 100 connexions simultanées par seconde.

Exemple

La section tcp définit une règle de mise à l’échelle TCP.

Propriété de mise à l’échelle	Description	Valeur par défaut	Valeur min	Valeur max
`concurrentConnections`	Lorsque le nombre de connexions TCP simultanées dépasse cette valeur, un autre réplica est ajouté. Les réplicas continuent d’être ajoutés jusqu’à ce que la quantité `maxReplicas` soit atteinte, à mesure que le nombre de connexions simultanées augmente.	10	1	n/a

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "tcp-rule",
            "tcp": {
              "metadata": {
                "concurrentConnections": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Définissez une règle de mise à l’échelle TCP à l’aide du paramètre --scale-rule-tcp-concurrency dans les commandes create ou update.

Paramètre CLI	Description	Valeur par défaut	Valeur min	Valeur max
`--scale-rule-tcp-concurrency`	Lorsque le nombre de connexions TCP simultanées dépasse cette valeur, un autre réplica est ajouté. Les réplicas continuent d’être ajoutés jusqu’à ce que la quantité `max-replicas` soit atteinte, à mesure que le nombre de connexions simultanées augmente.	10	1	n/a

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --scale-rule-name azure-tcp-rule \
  --scale-rule-type tcp \
  --scale-rule-tcp-concurrency 100

Non pris en charge dans le portail Azure. Utilisez Azure CLI ou Azure Resource Manager pour configurer une règle de mise à l’échelle TCP.

Personnalisée

Vous pouvez créer une règle de mise à l’échelle Container Apps personnalisée en fonction de n’importe quel processus de mise à l’échelle KEDA basé sur ScaledObject avec les valeurs par défaut suivantes :

Valeurs par défaut	Secondes
Fréquence d’interrogation	30
Période de refroidissement	300

Pour les travaux Container Apps pilotés par les événements, vous pouvez créer une règle de mise à l’échelle personnalisée en fonction des processus de mise à l’échelle KEDA basés sur ScaledJob.

L’exemple suivant montre comment créer une règle de mise à l’échelle personnalisée.

Exemple

Cet exemple montre comment convertir un processus de mise à l’échelle Azure Service Bus en règle de mise à l’échelle Container Apps. Toutefois, vous utilisez le même processus pour toute autre spécification de processus de mise à l’échelle KEDA basé sur ScaledObject.

Pour l’authentification, les paramètres d’authentification du processus de mise à l’échelle KEDA sont convertis en secrets Container Apps.

La procédure suivante vous montre comment convertir un processus de mise à l’échelle KEDA en règle de mise à l’échelle Container Apps. Cet extrait de code provient d’un modèle ARM. Il vous montre la place de chaque section dans le contexte du modèle global.

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "configuration": {
        ...
        "secrets": [
          {
            "name": "<NAME>",
            "value": "<VALUE>"
          }
        ]
      },
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [
            {
              "name": "<RULE_NAME>",
              "custom": {
                "metadata": {
                  ...
                },
                "auth": [
                  {
                    "secretRef": "<NAME>",
                    "triggerParameter": "<PARAMETER>"
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
}

Consultez cet extrait pour obtenir un contexte sur la façon dont les exemples ci-dessous s’intègrent au modèle ARM.

Vous allez d’abord définir le type et les métadonnées de la règle de mise à l’échelle.

Dans la spécification du processus de mise à l’échelle KEDA, recherchez la valeur de type.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Dans le modèle ARM, entrez la valeur de type du processus de mise à l’échelle au sein de la propriété custom.type de la règle de mise à l’échelle.

...
"rules": [
  {
    "name": "azure-servicebus-queue-rule",
    "custom": {
      "type": "azure-servicebus",
      "metadata": {
        "queueName": "my-queue",
        "namespace": "service-bus-namespace",
        "messageCount": "5"
      }
    }
  }
]
...

Dans la spécification du processus de mise à l’échelle KEDA, recherchez les valeurs de metadata.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Dans le modèle ARM, ajoutez toutes les valeurs de métadonnées à la section custom.metadata de la règle de mise à l’échelle.

...
"rules": [
  {
    "name": "azure-servicebus-queue-rule",
    "custom": {
      "type": "azure-servicebus",
      "metadata": {
        "queueName": "my-queue",
        "namespace": "service-bus-namespace",
        "messageCount": "5"
      }
    }
  }
]
...

Authentification

Un processus de mise à l’échelle KEDA peut prendre en charge l’utilisation de secrets dans un TriggerAuthentication référencé par la propriété authenticationRef. Vous pouvez mapper l’objet TriggerAuthentication à la règle de mise à l’échelle Container Apps.

Remarque

Les règles de mise à l’échelle Container Apps prennent uniquement en charge les références de secrets. Les autres types d’authentifications, par exemple l’identité de pod, ne sont pas pris en charge.

Recherchez l’objet TriggerAuthentication référencé par la spécification d’un ScaledObject KEDA.

Dans la spécification KEDA, recherchez chaque secretTargetRef de l’objet TriggerAuthentication ainsi que son secret associé.

apiVersion: v1
kind: Secret
metadata:
  name: my-secrets
  namespace: my-project
type: Opaque
data:
  connection-string-secret: <SERVICE_BUS_CONNECTION_STRING>
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-servicebus-auth
spec:
  secretTargetRef:
  - parameter: connection
    name: my-secrets
    key: connection-string-secret
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-servicebus-queue-rule
  namespace: default
spec:
  scaleTargetRef:
    name: my-scale-target
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: my-queue
      namespace: service-bus-namespace
      messageCount: "5"
    authenticationRef:
        name: azure-servicebus-auth

Dans le modèle ARM, ajoutez toutes les entrées au tableau auth de la règle de mise à l’échelle.

Ajoutez un secret au tableau secrets de l’application conteneur contenant la valeur du secret.
Affectez à la propriété triggerParameter la valeur de la propriété key de TriggerAuthentication.
Affectez à la valeur de la propriété secretRef le nom du secret Container Apps.

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "configuration": {
        ...
        "secrets": [
          {
            "name": "connection-string-secret",
            "value": "<SERVICE_BUS_CONNECTION_STRING>"
          }
        ]
      },
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [
            {
              "name": "azure-servicebus-queue-rule",
              "custom": {
                "type": "azure-servicebus",
                "metadata": {
                  "queueName": "my-queue",
                  "namespace": "service-bus-namespace",
                  "messageCount": "5"
                },
                "auth": [
                  {
                    "secretRef": "connection-string-secret",
                    "triggerParameter": "connection"
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
}

Certains processus de mise à l’échelle prennent en charge les métadonnées ayant le suffixe FromEnv pour référencer une valeur dans une variable d’environnement. Container Apps examine le premier conteneur listé dans le modèle ARM pour la variable d’environnement.

Pour plus d’informations relatives à la sécurité, consultez la section Considérations.

Dans la spécification du processus de mise à l’échelle KEDA, recherchez la valeur de type.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Dans la commande CLI, affectez au paramètre --scale-rule-type la valeur de type de la spécification.

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
  --scale-rule-name azure-servicebus-queue-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata "queueName=my-queue" \
                        "namespace=service-bus-namespace" \
                        "messageCount=5" \
  --scale-rule-auth "connection=connection-string-secret"

Dans la spécification du processus de mise à l’échelle KEDA, recherchez les valeurs de metadata.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Dans la commande CLI, affectez au paramètre --scale-rule-metadata les valeurs de métadonnées.

Vous devez transformer les valeurs au format YAML en une paire clé-valeur à utiliser sur la ligne de commande. Séparez chaque paire clé-valeur par un espace.

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
  --scale-rule-name azure-servicebus-queue-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata "queueName=my-queue" \
                        "namespace=service-bus-namespace" \
                        "messageCount=5" \
  --scale-rule-auth "connection=connection-string-secret"

Authentification

Un processus de mise à l’échelle KEDA peut prendre en charge l’utilisation de secrets dans un TriggerAuthentication référencé par la propriété authenticationRef. Vous pouvez mapper l’objet TriggerAuthentication à la règle de mise à l’échelle Container Apps.

Remarque

Recherchez l’objet TriggerAuthentication référencé par la spécification d’un ScaledObject KEDA. Identifiez chaque secretTargetRef de l’objet TriggerAuthentication.

apiVersion: v1
kind: Secret
metadata:
  name: my-secrets
  namespace: my-project
type: Opaque
data:
  connection-string-secret: <SERVICE_BUS_CONNECTION_STRING>
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-servicebus-auth
spec:
  secretTargetRef:
  - parameter: connection
    name: my-secrets
    key: connection-string-secret
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-servicebus-queue-rule
  namespace: default
spec:
  scaleTargetRef:
    name: my-scale-target
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: my-queue
      namespace: service-bus-namespace
      messageCount: "5"
    authenticationRef:
        name: azure-servicebus-auth

Dans votre application conteneur, créez les secrets qui correspondent aux propriétés secretTargetRef.

Dans la commande CLI, définissez les paramètres de chaque entrée secretTargetRef.

Créez une entrée secrète avec le paramètre --secrets. S’il existe plusieurs secrets, séparez-les par un espace.
Créez une entrée d’authentification avec le paramètre --scale-rule-auth. S’il existe plusieurs entrées, séparez-les par un espace.

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
  --scale-rule-name azure-servicebus-queue-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata "queueName=my-queue" \
                        "namespace=service-bus-namespace" \
                        "messageCount=5" \
  --scale-rule-auth "connection=connection-string-secret"

Accédez à votre application conteneur dans le portail Azure.
Sélectionnez Mettre à l’échelle.
Sélectionnez Modifier et déployer.
Sélectionnez l’onglet Mettre à l’échelle et réplicas.
Sélectionnez la plage de réplicas minimale et maximale.
Sélectionnez Ajouter.
Dans la zone Nom de la règle, entrez un nom de règle.
Dans la liste déroulante Type, sélectionnez Personnalisé.

Dans la spécification du processus de mise à l’échelle KEDA, recherchez la valeur de type.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Dans la zone Type de règle personnalisée, entrez la valeur type du processus de mise à l’échelle.

Dans la spécification du processus de mise à l’échelle KEDA, recherchez les valeurs de metadata.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Dans le portail, recherchez la section Métadonnées, puis sélectionnez Ajouter. Entrez le nom et la valeur de chaque élément dans la section metadata de la spécification d’un ScaledObject KEDA.

Authentification

Remarque

Dans votre application conteneur, créez les secrets à référencer.

Recherchez l’objet TriggerAuthentication référencé par la spécification d’un ScaledObject KEDA. Identifiez chaque secretTargetRef de l’objet TriggerAuthentication.

apiVersion: v1
kind: Secret
metadata:
  name: my-secrets
  namespace: my-project
type: Opaque
data:
  connection-string-secret: <SERVICE_BUS_CONNECTION_STRING>
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-servicebus-auth
spec:
  secretTargetRef:
  - parameter: connection
    name: my-secrets
    key: connection-string-secret
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-servicebus-queue-rule
  namespace: default
spec:
  scaleTargetRef:
    name: my-scale-target
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: my-queue
      namespace: service-bus-namespace
      messageCount: "5"
    authenticationRef:
        name: azure-servicebus-auth

Dans la section Authentification, sélectionnez Ajouter afin de créer une entrée pour chaque paramètre secretTargetRef KEDA.

Règle de mise à l’échelle par défaut

Si vous ne créez pas de règle de mise à l’échelle, la règle de mise à l’échelle par défaut est appliquée à votre application conteneur.

Déclencheur	Nb min. de réplicas	Nb max. de réplicas
HTTP	0	10

Important

Veillez à créer une règle de mise à l’échelle, ou à affecter à minReplicas une valeur supérieure ou égale à 1, si vous n’activez pas l’entrée. Si l’entrée est désactivée et si vous ne définissez pas de minReplicas ou de règle de mise à l’échelle personnalisée, votre application conteneur est mise à l’échelle à zéro, et n’a aucun moyen de démarrer une sauvegarde.

Comportement de mise à l’échelle

Le comportement de mise à l’échelle présente les valeurs par défaut suivantes :

Paramètre	Valeur
Fréquence d’interrogation	30 secondes
Période de refroidissement	300 secondes
Effectuer un scale-up de la fenêtre de stabilisation	0 seconde
Effectuer un scale-down de la fenêtre de stabilisation	300 secondes
Étape de scale-up	1, 4, 100 % de l’actuel
Étape de scale-down	100 % de l’actuel
Algorithme de mise à l’échelle	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

L’intervalle d’interrogation correspond à la fréquence à laquelle les sources d’événements sont interrogées par KEDA. Cette valeur ne s’applique pas aux règles de mise à l’échelle HTTP et TCP.
La période de refroidissement correspond à la durée écoulée après l’observation du dernier événement, et avant que l’application n’effectue un scale-down du nombre minimal de réplicas.
La fenêtre de stabilisation de scale-up correspond à la durée d’attente avant la prise d’une décision de scale-up, une fois que les conditions de scale-up sont remplies.
La fenêtre de stabilisation de scale-down correspond à la durée d’attente avant la prise d’une décision de scale-down, une fois que les conditions de scale-down sont remplies.
L’étape de scale-up correspond à la fréquence à laquelle de nouvelles instances sont ajoutées. Elle commence par 1, 4, 8, 16, 32, ... jusqu’au nombre maximal de réplicas configuré.
L’étape de scale-down correspond à la fréquence à laquelle les réplicas sont supprimés. Par défaut, 100 % des réplicas qui doivent être arrêtés sont supprimés.
L’algorithme de mise à l’échelle est la formule utilisée pour calculer le nombre actuel souhaité de réplicas.

Exemple

Pour la règle de mise à l’échelle suivante :

"minReplicas": 0,
"maxReplicas": 20,
"rules": [
  {
    "name": "azure-servicebus-queue-rule",
    "custom": {
      "type": "azure-servicebus",
      "metadata": {
        "queueName": "my-queue",
        "namespace": "service-bus-namespace",
        "messageCount": "5"
      }
    }
  }
]

En partant d’une file d’attente vide, KEDA suit les étapes ci-dessous dans un scénario de scale-up :

Vérifier my-queue toutes les 30 secondes.
Si la longueur de la file d’attente est égale à 0, revenir à (1).
Si la longueur de la file d’attente est > 0, effectuer une mise à l’échelle de l’application à 1.
Si la longueur de la file d’attente est égale à 50, calculer desiredReplicas = ceil(50/5) = 10.
Mettre à l’échelle l’application à min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
Retourner à (1).

Si l’application a été mise à l’échelle en fonction du nombre maximal de réplicas, à savoir 20, la mise à l’échelle passe par les mêmes étapes précédentes. Le scale-down a lieu uniquement si la condition est satisfaite pendant 300 secondes (fenêtre de stabilisation de scale-down). Une fois que la longueur de la file d’attente est égale à 0, KEDA attend 300 secondes (période de refroidissement) avant de mettre à l’échelle l’application à 0.

À propos de l’installation

En mode de « révisions multiples », l’ajout d’un nouveau déclencheur de mise à l’échelle crée une révision de votre application, mais votre ancienne révision reste disponible avec les anciennes règles de mise à l’échelle. Utilisez la page Gestion des révisions pour gérer les allocations de trafic.
Aucun frais n’est encouru quand une application est mise à l’échelle à zéro. Pour plus d’informations sur les tarifs, consultez Facturation dans Azure Container Apps.
Vous devez activer la protection des données pour toutes les applications .NET sur Azure Container Apps. Pour plus d’informations, consultez Déploiement et mise à l’échelle d’une application ASP.NET Core sur Azure Container Apps.

Limitations connues

La mise à l’échelle verticale n’est pas prise en charge.
Les quantités de réplicas sont un chiffre cible et non une garantie.
Si vous utilisez des acteurs Dapr pour gérer les états, gardez à l’esprit que la mise à l’échelle à zéro n’est pas prise en charge. Dapr utilise des acteurs virtuels pour gérer les appels asynchrones, ce qui signifie que leur représentation en mémoire n’est pas liée à leur identité ni à leur durée de vie.

Étapes suivantes

Gérer les secrets

Définir des règles de mise à l’échelle dans Azure Container Apps

Définition de mise à l’échelle

Règles de mise à l’échelle

HTTP

Exemple

TCP

Exemple

Personnalisée

Exemple

Authentification

Authentification

Authentification

Règle de mise à l’échelle par défaut

Comportement de mise à l’échelle

Exemple

À propos de l’installation

Limitations connues

Étapes suivantes

Ressources supplémentaires