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

Article
07/29/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. Pour savoir quels types de changements déclenchent une nouvelle révision, consultez les types de changements de 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 la combinaison de limites, de règles et d’un comportement.

Les limites définissent le nombre minimal et le nombre 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	Le maximum de répliques configurables est de 1000.
Nombre maximal de réplicas par révision	10	1	Le maximum de répliques configurables est de 1000.

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 dans un format HTTP, TCP ou personnalisé.
Le comportement est la combinaison de règles et de limites déterminant 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 prises.

À mesure que vous définissez vos règles de mise à l’échelle, il est important de prendre en compte 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 inférieur « inactivité ». 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 \
  --transport tcp \
  --ingress <external/internal> \
  --target-port <CONTAINER_TARGET_PORT> \
  --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 scaler (outil de mise à l’échelle) KEDA prennent des secrets Container Apps ou des identités managées.

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

Les règles de mise à l’échelle Container Apps prennent en charge l’authentification basée sur les secrets. Les règles de mise à l’échelle pour les ressources Azure, notamment Stockage File d’attente Azure et Azure Event Hubs, prennent également en charge les identités managées. Dans la mesure du possible, utilisez l’authentification par identité managée pour éviter de stocker des secrets dans l’application.

Utilisez des secrets

Si vous souhaitez utiliser des secrets pour l’authentification, vous devez créer un secret dans le tableau secrets de l’application conteneur. La valeur de secret est utilisée dans le tableau auth de la règle de mise à l’échelle.

Les scalers KEDA peuvent utiliser des secrets dans une ressource TriggerAuthentication référencée par la propriété authenticationRef. Vous pouvez mapper l’objet TriggerAuthentication à la règle de mise à l’échelle Container Apps.

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

Dans l’objet TriggerAuthentication, recherchez chaque secretTargetRef et 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, pour chaque secret :

Ajoutez un secret au tableau secrets de l’application conteneur contenant la valeur et le nom du secret.
Ajoutez une entrée au tableau auth de la règle de mise à l’échelle.
1. Affectez à la propriété triggerParameter la valeur de la propriété parameter de secretTargetRef.
2. Définissez la valeur de la propriété secretRef sur le nom de la propriété key de secretTargetRef.

{
  ...
  "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.

Utilisation d’une identité managée

Les règles de mise à l’échelle de Container Apps peuvent utiliser une identité managée pour l’authentification auprès des services Azure. Le modèle ARM suivant transmet une identité managée basée sur le système pour authentifier un scaler de File d’attente Azure.

"scale": {
  "minReplicas": 0,
  "maxReplicas": 4,
  "rules": [
    {
      "name": "azure-queue",
      "custom": {
        "type": "azure-queue",
        "metadata": {
          "accountName": "apptest123",
          "queueName": "queue1",
          "queueLength": "1"
        },
        "identity": "system"
      }
    }
  ]
}

Pour découvrir plus d’informations sur l’utilisation d’identités managées avec des règles de mise à l’échelle, consultez Identité managée.

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

Utilisez des secrets

Pour configurer l’authentification basée sur les secrets pour une règle de mise à l’échelle, vous configurez les secrets dans l’application conteneur et vous les référencez dans la règle de mise à l’échelle.

Un scaler KEDA prend en charge les secrets dans une ressource TriggerAuthentication référencée par la propriété authenticationRef. Vous pouvez mapper l’objet TriggerAuthentication à la règle de mise à l’échelle de Container Apps.

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"

Utilisation d’une identité managée

Les règles de mise à l’échelle de Container Apps peuvent utiliser une identité managée pour l’authentification auprès des services Azure. La commande suivante crée une application conteneur avec une identité managée affectée par l’utilisateur et l’utilise pour authentifier un scaler File d’attente Azure.

az containerapp create \
  --resource-group <RESOURCE_GROUP> \
  --name <APP_NAME> \
  --environment <ENVIRONMENT_ID> \
  --user-assigned <USER_ASSIGNED_IDENTITY_ID> \
  --scale-rule-name azure-queue \
  --scale-rule-type azure-queue \
  --scale-rule-metadata "accountName=<AZURE_STORAGE_ACCOUNT_NAME>" "queueName=queue1" "queueLength=1" \
  --scale-rule-identity <USER_ASSIGNED_IDENTITY_ID>

Remplacez les espaces réservés par vos valeurs.

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

Utilisez des secrets

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.

Utilisation d’une identité managée

L’authentification par identité managée n’est pas prise en charge dans le Portail Azure. Utilisez l’interface Azure CLI ou Azure Resource Manager pour vous identifier en utilisant une identité managée.

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"
      }
    }
  }
]

À mesure que votre application effectue un scale-out, KEDA démarre avec une file d’attente vide et effectue les étapes suivantes :

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

Partage via

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

Utilisez des secrets

Utilisation d’une identité managée

Authentification

Utilisez des secrets

Utilisation d’une identité managée

Authentification

Utilisez des secrets

Utilisation d’une identité managée

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

Comportement de mise à l’échelle

Exemple

À propos de l’installation

Limitations connues

Étapes suivantes

Commentaires

Ressources supplémentaires