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

2025-05-21

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.

Pour prendre en charge ce comportement de mise à l’échelle, Azure Container Apps est alimenté par KEDA (mise à l’échelle automatique basée sur les événements Kubernetes). KEDA prend en charge la mise à l’échelle sur diverses métriques telles que les requêtes HTTP, les messages de file d’attente, le processeur et la charge de mémoire, et les sources d’événements telles qu’Azure Service Bus, Azure Event Hubs, Apache Kafka et Redis. Pour plus d’informations, consultez Scalers dans la documentation KEDA.

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 d'é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 « d’inactivité » moins élevé. Pour plus d'informations, consultez Facturation.
Si vous souhaitez vous assurer qu’une instance de votre version 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

Trois catégories de déclencheurs déterminent la façon dont la mise à l’échelle se produit :

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 des métriques personnalisées telles que :
- CPU (Unité centrale de traitement)
- Mémoire
- Sources de données pilotées par les événements prises en charge :
  - Azure Service Bus (Bus de service Azure)
  - 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 effectuer 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	Descriptif	Valeur par défaut	Valeur min	Valeur max
`concurrentRequests`	Quand le nombre de requêtes HTTP dépasse cette valeur, une autre réplique est ajoutée. Les réplicas continuent d’être ajoutés au pool jusqu’à ce que la quantité `maxReplicas` soit atteinte.	10	1	n/a

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 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.

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

Propriété de mise à l’échelle	Descriptif	Valeur par défaut	Valeur min	Valeur max
`concurrentRequests`	Quand le nombre de requêtes HTTP dépasse cette valeur, une autre réplique est ajoutée. 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

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	Descriptif	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, une autre réplique est ajoutée. 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 Échelle.
Sélectionnez Modifier et déployer.
Sélectionnez l’onglet É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 Scalabilité 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 tcp section définit une règle d’échelle TCP.

Propriété de mise à l’échelle	Descriptif	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

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'tcp-rule'
            http: {
              metadata: {
                concurrentConnections: '100'
              }
            }
          }
        ]
      }
    }
  }
}

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

Propriété de mise à l’échelle	Descriptif	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	Descriptif	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, Azure Resource Manager ou Bicep pour configurer une règle de mise à l’échelle TCP.

Personnalisé

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 de l’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 outil de mise à l’échelle KEDA en règle de mise à l’échelle Container Apps. Cet extrait de code est un extrait d’un modèle Bicep pour vous montrer où chaque section s’adapte dans le contexte du modèle global.

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    configuration: {
      ...
      secrets: [
        {
          name: '<NAME>'
          value: '<VALUE>'
        }
      ]
    }
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: '<RULE_NAME>'
            custom: {
              metadata: {
                ...
              }
              auth: [
                {
                  secretRef: '<NAME>'
                  triggerParameter: '<PARAMETER>'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Reportez-vous à cet extrait pour obtenir un contexte sur la façon dont les exemples ci-dessous s’intègrent dans le modèle Bicep.

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

Dans la description du scaler KEDA, recherchez la valeur de type.

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

Dans le modèle Bicep, entrez la valeur du scaler type dans la custom.type propriété de la règle d’é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 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 Bicep, ajoutez toutes les valeurs de métadonnées à la custom.metadata section de la règle d’é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 outils de mise à l’échelle 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 KEDA ScaledObject.

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 Bicep, pour chaque secret :

Ajoutez un secret au tableau secrets de l’application conteneur contenant le nom et la valeur 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é secretTargetRef de parameter.
2. Attribuez à la propriété secretRef le nom de la propriété secretTargetRef de key.

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    configuration: {
      ...
      secrets: [
        {
          name: 'connection-string-secret'
          value: '<SERVICE_BUS_CONNECTION_STRING>'
        }
      ]
    }
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 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 Bicep suivant transmet une identité managée basée sur le système pour authentifier un outil de mise à l’échelle de File d’attente Azure.

Avant d'utiliser le code suivant, remplacez les balises entourées par <> par vos valeurs.

scale: {
  minReplicas: 0
  maxReplicas: 4
  rules: [
    {
      name: 'azure-queue'
      custom: {
        type: 'azure-queue'
        metadata: {
          accountName: '<ACCOUNT_NAME>'
          queueName: '<QUEUE_NAME>'
          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.

La procédure suivante vous montre comment convertir un outil 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 description du scaler 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 du scaler type dans 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 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

Utilisez des secrets

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

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 le nom et la valeur 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é secretTargetRef de parameter.
2. Attribuez à la propriété secretRef le nom de la propriété secretTargetRef de key.

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

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 outil de mise à l’échelle de File d’attente Azure.

Avant d'utiliser le code suivant, remplacez les balises entourées par <> par vos valeurs.

"scale": {
  "minReplicas": 0,
  "maxReplicas": 4,
  "rules": [
    {
      "name": "azure-queue",
      "custom": {
        "type": "azure-queue",
        "metadata": {
          "accountName": "<ACCOUNT_NAME>",
          "queueName": "<QUEUE_NAME>",
          "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 description du scaler 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 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 outil de mise à l’échelle 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 KEDA ScaledObject. 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 outil de mise à l’échelle File d’attente Azure.

Avant d'utiliser le code suivant, remplacez les balises entourées par <> par vos valeurs.

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>

Accédez à votre application conteneur dans le portail Azure.
Sélectionnez É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 description du scaler 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 d'échelle type.

Dans la spécification 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 des métadonnées de la spécification KEDA ScaledObject.

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 KEDA ScaledObject. 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	Nombre maximal de répliques
HTTP	0	10

Important

Veillez à créer une règle de mise à l’échelle, ou définir minReplicas sur 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
Augmenter la fenêtre de stabilisation	0 seconde
Réduire la fenêtre de stabilisation	300 secondes
Étape pour effectuer un scale-up	1, 4, 100 % de l’actuel
Étape de réduction	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, avant que l’application ne réduise son nombre de réplicas au minimum.
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 pour effectuer un 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 prend de l'ampleur, KEDA démarre avec une file d’attente vide et exécute 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.

Considérations

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 ne sont appliqués lorsque une application est réduite à 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épliques sont un objectif 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.
La modification des proxys KEDA via les paramètres de proxys n’est pas prise en charge. Pensez à utiliser des profils de charge de travail avec une passerelle NAT ou un itinéraire défini par l’utilisateur (UDR) pour envoyer le trafic à une appliance de réseau, où le trafic peut être inspecté ou proxysé à partir de là.

Étapes suivantes

Gérer les secrets

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

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

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

Considérations

Limitations connues

Étapes suivantes

Commentaires

Ressources supplémentaires