Impostare le regole di ridimensionamento in App contenitore di Azure

App contenitore di Azure gestisce il ridimensionamento orizzontale automatico tramite un set di regole di ridimensionamento dichiarativo. Quando una revisione di un'app contenitore si espande, la piattaforma crea nuove istanze della revisione su richiesta. Queste istanze sono note come repliche.

Per supportare questo comportamento di ridimensionamento, App contenitore di Azure usa KEDA (Scalabilità automatica guidata dagli eventi kubernetes). KEDA supporta il ridimensionamento rispetto a un'ampia gamma di metriche, ad esempio richieste HTTP, messaggi di coda, carico di CPU e memoria e origini eventi come bus di servizio di Azure, Hub eventi di Azure, Apache Kafka e Redis. Per altre informazioni, vedere Scaler nella documentazione di KEDA.

Quando si aggiungono o si modificano regole di ridimensionamento, si crea una nuova revisione dell'app contenitore. Una revisione è uno snapshot non modificabile dell'app contenitore. Per informazioni sui tipi di modifiche che attivano una nuova revisione, vedere tipi di modifica delle revisioni.

I processi di app contenitore basati su eventi usano le regole di ridimensionamento per attivare le esecuzioni in base agli eventi.

Definizione della scala

Il ridimensionamento è la combinazione di limiti, regole e comportamento.

I limiti definiscono il numero minimo e massimo possibile di repliche per revisione man mano che l'app contenitore viene ridimensionata.

Limite di scalabilità	Valore predefinito	Valore minimo	Valore massimo
Numero minimo di repliche per revisione	0	0	Il numero massimo di repliche configurabili è 1.000.
Numero massimo di repliche per revisione	10	1	Il numero massimo di repliche configurabili è 1.000.

Le regole sono i criteri usati dalle app contenitore per decidere quando aggiungere o rimuovere repliche.

Le regole di scalabilità vengono implementate come HTTP, TCP (Transmission Control Protocol) o personalizzate.
Il comportamento è la combinazione di regole e limiti per determinare le decisioni di scalabilità nel tempo.

Il comportamento di scalabilità spiega come vengono prese decisioni sulla scalabilità.

Quando si definiscono le regole di ridimensionamento, considerare gli elementi seguenti:

Non vengono addebitati costi per l'utilizzo se l'app contenitore viene ridimensionata a zero.
Le repliche che non eseguono elaborazioni ma rimangono in memoria potrebbero essere fatturate a una tariffa di "inattività" inferiore. Per altre informazioni, vedereFatturazione.
Per assicurarsi che un'istanza della revisione sia sempre in esecuzione, impostare il numero minimo di repliche su 1 o superiore.
Durante gli aggiornamenti o la manutenzione della piattaforma, è possibile visualizzare temporaneamente più repliche del previsto. Le app contenitore garantiscono che il carico di lavoro di produzione non venga influenzato dal pre-riscaldamento di nuove repliche prima di spostare il traffico, simile al comportamento predefinito di Kubernetes. Le repliche aggiuntive vengono rimosse automaticamente al termine dell'operazione.

Regole di scalabilità

Tre categorie di trigger determinano la modalità di ridimensionamento:

HTTP: in base al numero di richieste HTTP simultanee della tua revisione.
TCP: in base al numero di connessioni TCP simultanee della tua revisione.
Personalizzato: in base a metriche personalizzate come:
- CPU (unità centrale di elaborazione)
- Memoria
- Origini dati basate su eventi supportate:
  - bus di servizio di Azure
  - Hub eventi di Azure
  - Apache Kafka
  - Redis

Se si definisce più di una regola di scalabilità, l'app contenitore inizia la scalabilità non appena viene soddisfatta la prima condizione di una qualsiasi delle regole.

Nota

Se si usano funzioni nelle app contenitore, l'esperienza predefinita configura automaticamente le regole di scalabilità in base ai trigger e alle associazioni delle funzioni. Il portale di Azure disabilita il pulsante Aggiungi regole di scalabilità per queste app. Se hai bisogno di regole definite dal cliente, usa allowScalingRuleOverride come descritto in Sostituire le regole di scalabilità KEDA generate automaticamente per Funzioni di Azure su Container Apps.

Protocollo HTTP

Quando si usa una regola di ridimensionamento HTTP, si controlla la soglia delle richieste HTTP simultanee che determinano la scalabilità delle revisioni dell'app contenitore. Ogni 15 secondi, il numero di richieste simultanee viene calcolato come numero di richieste negli ultimi 15 secondi diviso per 15. Le attività di Container Apps non supportano le regole di scalabilità HTTP.

Nell'esempio seguente la revisione aumenta fino a cinque repliche e può essere ridotta a zero. La proprietà di ridimensionamento è impostata su 100 richieste simultanee al secondo.

Esempio

La sezione http definisce una regola di scalabilità HTTP.

Proprietà di ridimensionamento	Descrizione	Valore predefinito	Valore minimo	Valore massimo
`concurrentRequests`	Quando il numero di richieste HTTP supera questo valore, l'app aggiunge un'altra replica. L'app continua ad aggiungere repliche fino alla quantità di `maxReplicas`.	10	1	n/d

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

Nota

Impostare la properties.configuration.activeRevisionsMode proprietà dell'app contenitore su single quando si usano regole di scalabilità di eventi non HTTP.

La sezione http definisce una regola di scalabilità HTTP.

Proprietà di ridimensionamento	Descrizione	Valore predefinito	Valore minimo	Valore massimo
`concurrentRequests`	Quando il numero di richieste HTTP supera questo valore, l'app aggiunge un'altra replica. L'app continua ad aggiungere repliche fino al numero `maxReplicas`.	10	1	n/d

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

Nota

Impostare la properties.configuration.activeRevisionsMode proprietà dell'app contenitore su single quando si usano regole di scalabilità di eventi non HTTP.

Definire una regola di scalabilità HTTP usando il parametro --scale-rule-http-concurrency nei comandi create o update.

Parametro CLI	Descrizione	Valore predefinito	Valore minimo	Valore massimo
`--scale-rule-http-concurrency`	Quando il numero di richieste HTTP simultanee supera questo valore, l'app aggiunge un'altra replica. L'app continua ad aggiungere repliche fino a raggiungere la quantità `max-replicas`.	10	1	n/d

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

Vai all'app container nel "portale di Azure".
Selezionare Ridimensiona.
Selezionare Modifica e distribuisci.
Fare clic sulla scheda Scalabilità.
Selezionare l'intervallo minimo e massimo di repliche.
Selezionare Aggiungi.
Nella casella Nome regola immettere un nome per la regola.
Nell'elenco a discesa Tipo selezionare Ridimensionamento HTTP.
Nella casella Richieste simultanee immettere il numero di richieste simultanee desiderate per l'app contenitore.

TCP

Quando si usa una regola di ridimensionamento TCP, si controlla la soglia delle connessioni TCP simultanee che determinano la scalabilità dell'app. Ogni 15 secondi, il sistema calcola il numero di connessioni simultanee come numero di connessioni negli ultimi 15 secondi diviso per 15. I processi di App contenitore non supportano le regole di ridimensionamento TCP.

Nell'esempio seguente, la revisione dell'app contenitore può aumentare fino a cinque repliche e ridursi fino a zero. La soglia di ridimensionamento è impostata su 100 connessioni simultanee al secondo.

Esempio

La sezione tcp definisce una regola di scalabilità TCP.

Proprietà di ridimensionamento	Descrizione	Valore predefinito	Valore minimo	Valore massimo
`concurrentConnections`	Quando il numero di connessioni TCP simultanee supera questo valore, il sistema aggiunge un'altra replica. Il sistema continua ad aggiungere repliche fino a raggiungere la quantità `maxReplicas` man mano che aumenta il numero di connessioni contemporanee.	10	1	n/d

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 sezione tcp definisce una regola di scalabilità TCP.

Proprietà di ridimensionamento	Descrizione	Valore predefinito	Valore minimo	Valore massimo
`concurrentConnections`	Quando il numero di connessioni TCP simultanee supera questo valore, il sistema aggiunge un'altra replica. Il sistema continua ad aggiungere repliche fino alla quantità `maxReplicas` man mano che aumenta il numero di connessioni simultanee.	10	1	n/d

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

Definire una regola di scalabilità TCP usando il --scale-rule-tcp-concurrency parametro nei create comandi o update .

Parametro CLI	Descrizione	Valore predefinito	Valore minimo	Valore massimo
`--scale-rule-tcp-concurrency`	Quando il numero di connessioni TCP simultanee supera questo valore, il sistema aggiunge un'altra replica. Il sistema continua ad aggiungere repliche fino a raggiungere la quantità `max-replicas` man mano che aumenta il numero di connessioni simultanee.	10	1	n/d

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

Il portale di Azure non supporta questa funzionalità. Usare interfaccia della riga di comando di Azure, Azure Resource Manager o Bicep per configurare una regola di scalabilità TCP.

Personalizzazione

Creare una regola di ridimensionamento di App contenitore personalizzate in base a qualsiasi scaler KEDA basato su ScaledObject usando questi valori predefiniti:

Valore predefinito	Secondi
Intervallo di interrogazione	30
Periodo di raffreddamento	300

Nota

Il periodo di raffreddamento diventa effettivo solo quando si passa dalla replica finale a 0. Il periodo di raffreddamento non influisce sul ridimensionamento perché vengono rimosse altre repliche.

Per i processi di Container Apps basati su eventi, creare una regola di ridimensionamento personalizzata basata su uno qualsiasi degli scaler KEDA basati su ScaledJob.

Nell'esempio seguente viene illustrato come creare una regola di scalabilità personalizzata.

Esempio

Questo esempio illustra come convertire un bus di servizio di Azure scaler in una regola di scalabilità di App contenitore, ma si usa lo stesso processo per qualsiasi altra specifica ScaledObject basata su KEDA scaler.

Per l'autenticazione, i parametri di autenticazione dello scaler KEDA accettano i segreti o l'identità gestita delle app contenitore.

La procedura seguente illustra come convertire un'utilità di scalabilità KEDA in una regola di scalabilità dell'app contenitore. Questo frammento di codice è un estratto di un modello Bicep per mostrare dove ogni sezione rientra nel contesto del modello complessivo.

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

Fare riferimento a questo estratto per informazioni di contesto sul modo in cui gli esempi seguenti rientrano nel modello di Bicep.

Prima di tutto, definire il tipo e i metadati della regola di scalabilità.

Nella specifica dell'utilità di scalabilità KEDA trovare il valore type.

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

Nel modello Bicep immettere il valore del scaler type nella custom.type proprietà della regola di scalabilità.

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

Dalla specifica dell'utilità di scalabilità KEDA, trovare i valori metadata.

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

Nel modello Bicep aggiungere tutti i valori dei metadati alla custom.metadata sezione della regola di scalabilità.

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

Autenticazione

Le regole di scalabilità delle app per container supportano l'autenticazione basata su segreti. Le regole di scalabilità per le risorse di Azure, tra cui archiviazione code di Azure, bus di servizio di Azure e Hub eventi di Azure, supportano anche l'identità gestita. Se possibile, usare l'autenticazione dell'identità gestita per evitare di archiviare segreti all'interno dell'app.

Usa segreti

Per usare i segreti per l'autenticazione, creare un segreto nell'array dell'app contenitore secrets. Usare il valore segreto nell'array auth della regola di scalabilità.

Gli scaler KEDA possono usare segreti in un TriggerAuthentication a cui fa riferimento la proprietà authenticationRef. È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità di App contenitore.

Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA.

Nell'oggetto TriggerAuthentication trovare ogni secretTargetRef e il segreto associato.

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

Nel modello Bicep, per ogni segreto:

Aggiungere un segreto all'array secrets dell'app contenitore che include il nome e il valore del segreto.

Aggiungere una voce all'array di auth della regola di scalabilità.

Impostare il valore della proprietà triggerParameter sul valore della proprietà secretTargetRef di parameter.

Impostare il valore della proprietà secretRef sul nome della proprietà secretTargetRef di 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'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Alcune utilità di scalabilità supportano i metadati con il suffisso FromEnv per fare riferimento a un valore in una variabile di ambiente. L'app Container Apps esamina il primo contenitore elencato nel modello di ARM per la variabile di ambiente.

Per altre informazioni sulla sicurezza, vedere la sezione Considerazioni.

Uso dell'identità gestita

Le regole di scalabilità di App contenitore possono usare l'identità gestita per l'autenticazione con i servizi di Azure. Il modello Bicep seguente passa l'identità gestita basata sul sistema per eseguire l'autenticazione per un scaler della coda Azure.

Prima di usare il codice seguente, sostituire i segnaposto racchiusi tra <> con i vostri valori.

scale: {
  minReplicas: 0
  maxReplicas: 4
  rules: [
    {
      name: 'azure-queue'
      custom: {
        type: 'azure-queue'
        metadata: {
          accountName: '<ACCOUNT_NAME>'
          queueName: '<QUEUE_NAME>'
          queueLength: '1'
        },
        identity: 'system'
      }
    }
  ]
}

Per ulteriori informazioni sull'utilizzo dell'identità gestita con le regole di scalabilità, vedere Identità gestita.

La procedura seguente illustra come convertire un'utilità di scalabilità KEDA in una regola di scalabilità dell'app contenitore. Questo frammento di codice è un estratto di un modello di ARM che mostra la posizione di ogni sezione nel contesto del modello complessivo.

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

Fare riferimento a questo passaggio per capire il contesto di come gli esempi seguenti si inseriscono nel modello ARM.

Prima di tutto, definire il tipo e i metadati della regola di scalabilità.

Nella specifica dell'utilità di scalabilità KEDA trovare il valore type.

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

Nel modello ARM immettere il valore type del fattore di scala nella proprietà custom.type della regola di scala.

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

Dalla specifica dell'utilità di scalabilità KEDA, trovare i valori metadata.

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

Nel modello di ARM aggiungere tutti i valori dei metadati alla sezione custom.metadata della regola di scalabilità.

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

Autenticazione

Usa segreti

Per usare i segreti per l'autenticazione, crea un segreto nell'array secrets dell'app contenitore. Usare il valore segreto nell'array auth della regola di scaling.

Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA.

Nell'oggetto TriggerAuthentication trovare ogni secretTargetRef e il segreto associato.

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

Nel modello ARM, per ogni segreto:

Aggiungere un segreto all'array secrets dell'app contenitore che include il nome e il valore del segreto.
Aggiungere una voce all'array di auth della regola di scalabilità.
1. Impostare il valore della proprietà triggerParameter sul valore della proprietà secretTargetRef di parameter.
2. Impostare il valore della proprietà secretRef sul nome della proprietà secretTargetRef di 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"         ⬅️
                  }                                          ⬅️
                ]
              }
            }
          ]
        }
      }
    }
  }
}

Per altre informazioni sulla sicurezza, vedere la sezione Considerazioni.

Uso dell'identità gestita

Le regole di scalabilità di App contenitore possono usare l'identità gestita per l'autenticazione con i servizi di Azure. Il modello ARM seguente passa un'identità gestita assegnata dal sistema per l'autenticazione di uno scaler di Azure Queue.

Prima di usare il codice seguente, sostituire i segnaposto racchiusi tra <> con i vostri valori.

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

Per ulteriori informazioni sull'utilizzo dell'identità gestita con le regole di scalabilità, vedere Identità gestita.

Nella specifica dell'utilità di scalabilità KEDA trovare il valore type.

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

Nel comando dell'interfaccia della riga di comando impostare il parametro --scale-rule-type sul valore type della specifica.

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"

Dalla specifica dell'utilità di scalabilità KEDA, trovare i valori metadata.

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

Nel comando CLI, impostare il parametro --scale-rule-metadata sui valori dei metadati.

Trasformare i valori da un formato YAML a una coppia chiave/valore da usare nella riga di comando. Separare ogni coppia chiave-valore con uno spazio.

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"

Autenticazione

Usa segreti

Per configurare l'autenticazione basata su segreti per una regola di scalabilità di App contenitore, configurare i segreti nell'app contenitore e farvi riferimento nella regola di scalabilità.

Un'utilità di scalabilità KEDA supporta l'uso dei segreti in un oggetto TriggerAuthentication che la proprietà authenticationRef usa per riferimento. È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità di Container Apps.

Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA. Identificare ogni secretTargetRef dell'oggetto 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

Nell'app contenitore creare i segreti che corrispondono alle proprietà secretTargetRef.

Nel comando dell'interfaccia della riga di comando impostare i parametri per ogni voce secretTargetRef.

Creare una voce per il segreto con il parametro --secrets. Se sono presenti più segreti, separarli con uno spazio.
Creare una voce per l'autenticazione con il parametro --scale-rule-auth. Se sono presenti più voci, separarle con uno spazio.

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"                ⬅️

Uso dell'identità gestita

Le regole di scalabilità di App contenitore possono usare l'identità gestita per l'autenticazione con i servizi di Azure. Il comando seguente crea un'applicazione container con un'identità gestita utente-assegnata e la usa per autenticarsi presso uno scaler di Azure Queue.

Prima di usare il codice seguente, sostituire i segnaposto racchiusi tra <> con i vostri valori.

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>

Vai all'app container nel "portale di Azure".
Selezionare Ridimensiona.
Selezionare Modifica e distribuisci.
Selezionare la scheda Scalabilità e repliche.
Selezionare l'intervallo minimo e massimo di repliche.
Selezionare Aggiungi.
Nella casella Nome regola immettere un nome per la regola.
Nell'elenco a discesa Tipo selezionare Personalizzata.

Nella specifica dell'utilità di scalabilità KEDA trovare il valore type.

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

Nella casella Tipo di regola personalizzata immettere il valore dello scaler type.

Dalla specifica dell'utilità di scalabilità KEDA, trovare i valori metadata.

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

Nel portale individuare la sezione Metadati e selezionare Aggiungi. Immettere il nome e il valore per ogni elemento nella sezione relativa ai metadati della specifica ScaledObject KEDA.

Autenticazione

Usa segreti

Nell'app contenitore, crea i segreti a cui vuoi fare riferimento.

Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA. Identificare ogni secretTargetRef dell'oggetto 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

Nella sezione Autenticazione selezionare Aggiungi per creare una voce per ogni parametro secretTargetRef KEDA.

Uso dell'identità gestita

L'autenticazione dell'identità gestita non è supportata nella Azure portal. Usare interfaccia della riga di comando di Azure o Azure Resource Manager per eseguire l'autenticazione con l'identità gestita.

Regola di scalabilità predefinita

Se non si crea ua regola di scalabilità, all'app contenitore ne viene applicata una predefinita.

Attivatore	Numero minimo di repliche	Numero massimo di repliche
Protocollo HTTP	0	10

Importante

Assicurarsi di creare una regola di scalabilità o impostare minReplicas su 1 o più se non si abilitano i dati in ingresso. Se l'ingresso è disabilitato e non si definisce un minReplicas o una regola di scalabilità personalizzata, l'app contenitore viene scalata a zero e non ha modo di riavviarsi.

Comportamento della scalabilità

Il ridimensionamento ha i comportamenti seguenti:

Comportamento	Valore
Intervallo di interrogazione	30 secondi
Periodo di raffreddamento	300 secondi
Espandi la finestra di stabilizzazione	0 secondi
Riduzione della finestra di stabilizzazione	300 secondi
Passaggio di aumento delle prestazioni	1, 4, 8, 16, 32, ... fino al numero massimo di repliche configurato
Passaggio di riduzione delle prestazioni	100% delle repliche che devono essere arrestate
Algoritmo di ridimensionamento	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

L'intervallo di polling indica la frequenza con cui KEDA interroga le fonti degli eventi. Questo valore non si applica alle regole di scalabilità HTTP e TCP.
Il periodo di raffreddamento è il tempo che KEDA attende dopo l'ultimo evento prima che l'applicazione venga ridimensionata fino al numero minimo di repliche.
La finestra di stabilizzazione per lo scaling verso l’alto indica per quanto tempo KEDA attende prima di prendere una decisione di scaling verso l’alto, una volta soddisfatte le relative condizioni.
La finestra di stabilizzazione con riduzione è il tempo di attesa di KEDA prima di eseguire una decisione di riduzione delle prestazioni quando vengono soddisfatte le condizioni di riduzione delle prestazioni.
Il passaggio di aumento delle prestazioni è il numero di repliche aggiunte quando l'app contenitore viene ridimensionata. Inizia da 1, quindi aumenta a 4, 8, 16, 32 e così via, fino al numero massimo di repliche configurato.
Il passaggio di riduzione è il numero di repliche rimosse man mano che l'app contenitore viene ridimensionata. KEDA rimuove il 100% delle repliche che devono essere disattivate.
L'algoritmo di ridimensionamento è la formula usata per calcolare il numero corrente di repliche desiderate.

Esempio

Per la regola di scalabilità seguente:

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

Man mano che viene aumentato il numero di istanze dell'app, KEDA inizia con una coda vuota ed esegue i passaggi seguenti:

Controlla my-queue ogni 30 secondi.
Se la lunghezza della coda è uguale a 0, tornare al passaggio 1.
Se la lunghezza della coda è maggiore di 0, ridimensionare l'app a 1.
Se la lunghezza della coda è 50, calcola desiredReplicas = ceil(50/5) = 10.
Ridimensiona l'app a min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount)).
Tornare al passaggio 1.

Se l'app viene ridimensionata fino al numero massimo di repliche pari a 20, il ridimensionamento esegue gli stessi passaggi precedenti. La riduzione delle prestazioni si verifica solo se la condizione viene soddisfatta per 300 secondi (finestra di stabilizzazione ridotta). Quando la lunghezza della coda è 0, KEDA attende 300 secondi (periodo di raffreddamento) prima di ridimensionare l'app a 0.

Considerazioni

In modalità "più revisioni", l'aggiunta di un nuovo trigger di scalabilità crea una nuova revisione dell'applicazione, ma la revisione precedente rimane disponibile con le regole di scalabilità precedenti. Usare la pagina gestione delle revisioni per gestire le allocazioni del traffico.
Non vengono addebitati addebiti per l'utilizzo quando un'applicazione viene ridimensionata a zero. Per altre informazioni sui prezzi, vedere Billing in App contenitore di Azure.
È necessario abilitare la protezione dei dati per tutte le app .NET in App contenitore di Azure. Per informazioni dettagliate, vedere Distribuzione e ridimensionamento di un'app ASP.NET Core su App contenitore di Azure.

Limitazioni note

Il ridimensionamento verticale non è supportato.
Le quantità di repliche sono un obiettivo, non una garanzia.
Se si usano attori Dapr per gestire gli stati, tenere presente che il ridimensionamento a zero non è supportato. Dapr utilizza attori virtuali per gestire le chiamate asincrone, il che significa che la loro rappresentazione in memoria non è legata alla loro identità o durata.
La modifica dei proxy KEDA tramite le impostazioni dei proxy non è supportata. È consigliabile usare i profili di carico di lavoro con un gateway NAT o una route definita dall'utente (UDR) per inviare il traffico a un'appliance di rete, in cui è possibile controllare o proxy il traffico.

Passaggi successivi

Gestire i segreti

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-05-26

Impostare le regole di ridimensionamento in App contenitore di Azure

Definizione della scala

Regole di scalabilità

Protocollo HTTP

Esempio

TCP

Esempio

Personalizzazione

Esempio

Autenticazione

Usa segreti

Uso dell'identità gestita

Autenticazione

Usa segreti

Uso dell'identità gestita

Autenticazione

Usa segreti

Uso dell'identità gestita

Autenticazione

Usa segreti

Uso dell'identità gestita

Regola di scalabilità predefinita

Comportamento della scalabilità

Esempio

Considerazioni

Limitazioni note

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive