Condividi tramite


Impostare le regole di ridimensionamento in App contenitore di Azure

App contenitore di Azure gestisce la scalabilità orizzontale automatica tramite un set di regole di ridimensionamento dichiarative. Quando una revisione dell'app contenitore aumenta, vengono create nuove istanze della revisione su richiesta. Queste istanze sono note come repliche.

L'aggiunta o la modifica delle regole di ridimensionamento 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 del piano

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, è importante considerare gli elementi seguenti:

  • Non vengono addebitati costi per l'utilizzo se l'app contenitore viene ridimensionata a zero.
  • Le repliche che non sono in elaborazione, ma che 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.

Regole di scalabilità

Il ridimensionamento è basato su tre diverse categorie di trigger:

  • HTTP: in base al numero di richieste HTTP simultanee alla revisione.
  • TCP: in base al numero di connessioni TCP simultanee alla revisione.
  • Personalizzate: in base a CPU, memoria o origini dati basate su eventi supportate, ad esempio:
    • Bus di servizio di Azure
    • Hub eventi di Azure
    • Apache Kafka
    • Redis

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

HTTP

Con una regola di ridimensionamento HTTP, è possibile controllare la soglia delle richieste HTTP simultanee che determinano modalità di ridimensionamento 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. I processi di App contenitore non supportano le regole di ridimensionamento 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 Default value Valore minimo Valore massimo
concurrentRequests Quando il numero di richieste HTTP supera questo valore, viene aggiunta un'altra replica. Le repliche continuano a essere aggiunte al pool fino alla quantità di maxReplicas. 10 1 n/d
{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Nota

Impostare la proprietà properties.configuration.activeRevisionsMode 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 dell'interfaccia della riga di comando Descrizione Default value Valore minimo Valore massimo
--scale-rule-http-concurrency Quando il numero di richieste HTTP simultanee supera questo valore, viene aggiunta un'altra replica. Le repliche continuano a essere aggiunte al pool fino alla quantità di 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
  1. Passare all'app contenitore nel portale di Azure

  2. Selezionare Ridimensiona.

  3. Selezionare Modifica e distribuisci.

  4. Fare clic sulla scheda Scalabilità.

  5. Selezionare l'intervallo minimo e massimo di repliche.

    Screenshot del dispositivo di scorrimento dell'intervallo di scalabilità di App contenitore di Azure.

  6. Selezionare Aggiungi.

  7. Nella casella Nome regola immettere un nome per la regola.

  8. Nell'elenco a discesa Tipo selezionare Ridimensionamento HTTP.

  9. Nella casella Richieste simultanee immettere il numero desiderato di richieste simultanee per l'app contenitore.

TCP

Con una regola di ridimensionamento TCP, è possibile controllare la soglia delle connessioni TCP simultanee che determinano modalità di ridimensionamento dell'app. Ogni 15 secondi, il numero di connessioni simultanee viene calcolato 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 aumenta fino a cinque repliche e può essere ridotta 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 Default value Valore minimo Valore massimo
concurrentConnections Quando il numero di connessioni TCP simultanee supera questo valore, viene aggiunta un'altra replica. Le repliche continuano a essere aggiunte fino alla quantità di 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 parametro --scale-rule-tcp-concurrency nei comandi create o update.

Parametro dell'interfaccia della riga di comando Descrizione Default value Valore minimo Valore massimo
--scale-rule-tcp-concurrency Quando il numero di connessioni TCP simultanee supera questo valore, viene aggiunta un'altra replica. Le repliche continuano a essere aggiunte fino alla quantità di 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

Non supportata nel portale di Azure. Usare l'interfaccia della riga di comando di Azure o Azure Resource Manager per configurare una regola di scalabilità TCP.

Personalizzazione

È possibile creare una regola di ridimensionamento personalizzata per le app contenitore in base a qualsiasi utilità di scalabilità KEDA basata su ScaledObject con queste impostazioni predefinite:

Defaults Secondi
Intervallo di polling 30
Periodo di raffreddamento 300

Per i processi di App contenitore basati su eventi, è possibile creare una regola di ridimensionamento personalizzata in base a qualsiasi utilità di scalabilità KEDA basata su ScaledJob.

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

Esempio

Questo esempio illustra come convertire un'utilità di scalabilità del bus di servizio di Azure in una regola di scalabilità dell'app contenitore, ma si usa lo stesso processo per qualsiasi altra specifica di utilità di scalabilità KEDA basato su ScaledObject.

Per l'autenticazione, i parametri di autenticazione dello strumento di scalabilità KEDA vengono convertiti in segreti dell'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 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 estratto per informazioni sul contesto degli esempi seguenti all'interno del modello di ARM.

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

  1. 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"
    
  2. Nel modello di ARM immettere il valore type dell'utilità di scalabilità nella proprietà custom.type della regola di scalabilità.

    ...
    "rules": [
      {
        "name": "azure-servicebus-queue-rule",
        "custom": {
          "type": "azure-servicebus",
          "metadata": {
            "queueName": "my-queue",
            "namespace": "service-bus-namespace",
            "messageCount": "5"
          }
        }
      }
    ]
    ...
    
  3. 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"
    
  4. 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

Un'utilità di scalabilità KEDA supporta l'uso dei segreti in un oggetto TriggerAuthentication a cui fa riferimento la proprietà authenticationRef. È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità dell'app contenitore.

Nota

Le regole di scalabilità delle app contenitore supportano solo i riferimenti ai segreti. Altri tipi di autenticazione, ad esempio l'identità del pod, non sono supportati.

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

  2. Dalla specifica KEDA trovare ogni secretTargetRef dell'oggetto TriggerAuthentication 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
    
  3. Nel modello di ARM aggiungere tutte le voci alla matrice auth della regola di scalabilità.

    1. Aggiungere un segreto alla matrice secrets dell'app contenitore che include il valore del segreto.

    2. Impostare il valore della proprietà triggerParameter sul valore della proprietà key di TriggerAuthentication.

    3. Impostare il valore della proprietà secretRef sul nome del segreto dell'app contenitore.

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

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

    Per altre informazioni sulla sicurezza, vedere la sezione Considerazioni.

  1. 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"
    
  2. 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"
    
  3. 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"
    
  4. Nel comando dell'interfaccia della riga di comando impostare il parametro --scale-rule-metadata sui valori dei metadati.

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

Un'utilità di scalabilità KEDA supporta l'uso dei segreti in un oggetto TriggerAuthentication a cui fa riferimento la proprietà authenticationRef. È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità dell'app contenitore.

Nota

Le regole di scalabilità delle app contenitore supportano solo i riferimenti ai segreti. Altri tipi di autenticazione, ad esempio l'identità del pod, non sono supportati.

  1. Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA. Identificare ogni voce 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
    
  2. Nell'app contenitore creare i segreti che corrispondono alle proprietà secretTargetRef.

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

    1. Creare una voce per il segreto con il parametro --secrets. Se sono presenti più segreti, separarli con uno spazio.

    2. 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"
    
  1. Passare all'app contenitore nel portale di Azure.

  2. Selezionare Ridimensiona.

  3. Selezionare Modifica e distribuisci.

  4. Selezionare la scheda Scalabilità e repliche.

  5. Selezionare l'intervallo minimo e massimo di repliche.

    Screenshot del dispositivo di scorrimento dell'intervallo di scalabilità di App contenitore di Azure.

  6. Selezionare Aggiungi.

  7. Nella casella Nome regola immettere un nome per la regola.

  8. Nell'elenco a discesa Tipo selezionare Personalizzata.

  9. 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"
    
  10. Nella casella Tipo di regola personalizzata immettere il valore type dell'utilità di scalabilità.

  11. 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"
    
  12. 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

Un'utilità di scalabilità KEDA supporta l'uso dei segreti in un oggetto TriggerAuthentication a cui fa riferimento la proprietà authenticationRef. È possibile eseguire il mapping dell'oggetto TriggerAuthentication alla regola di scalabilità dell'app contenitore.

Nota

Le regole di scalabilità delle app contenitore supportano solo i riferimenti ai segreti. Altri tipi di autenticazione, ad esempio l'identità del pod, non sono supportati.

  1. Nell'app contenitore creare i segreti a cui si vuole fare riferimento.

  2. Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA. Identificare ogni voce 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
    
  3. Nella sezione Autenticazione selezionare Aggiungi per creare una voce per ogni parametro secretTargetRef KEDA.

Regola di scalabilità predefinita

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

Trigger Numero minimo di repliche Numero massimo di repliche
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 i dati in ingresso sono disabilitati e non si definisce un valore per minReplicas o una regola di scalabilità personalizzata, l'app contenitore verrà ridimensionata a zero e non sarà più possibile riavviarla.

Comportamento della scalabilità

Il comportamento di ridimensionamento prevede le impostazioni predefinite seguenti:

Parametro Valore
Intervallo di polling 30 secondi
Periodo di raffreddamento 300 secondi
Finestra di stabilizzazione per l'aumento delle prestazioni 0 secondi
Finestra di stabilizzazione per la riduzione delle prestazioni 300 secondi
Passaggio di aumento delle prestazioni 1, 4, 100% del valore corrente
Passaggio di riduzione delle prestazioni 100% del valore corrente
Algoritmo di ridimensionamento desiredReplicas = ceil(currentMetricValue / targetMetricValue)
  • L'intervallo di polling è la frequenza con cui KEDA esegue query sulle origini eventi. Questo valore non si applica alle regole di scalabilità HTTP e TCP.
  • Il periodo di raffreddamento indica quanto tempo dopo l'ultimo evento è trascorso prima che l'applicazione venga ridotta al numero minimo di repliche.
  • La finestra di stabilizzazione per l'aumento delle prestazioni è il tempo di attesa prima di eseguire una decisione di aumento delle prestazioni dopo che sono state soddisfatte le condizioni corrispondenti.
  • La finestra di stabilizzazione per la riduzione delle prestazioni è il tempo di attesa prima di eseguire una decisione di riduzione delle prestazioni dopo che sono state soddisfatte le condizioni corrispondenti.
  • Il passaggio di aumento delle prestazioni è la frequenza con cui vengono aggiunte nuove istanze. Inizia con 1, 4, 8, 16, 32, ... fino al numero massimo di repliche configurato.
  • Il passaggio di riduzione è la frequenza con cui vengono rimosse le repliche. Per impostazione predefinita, viene rimosso il 100% delle repliche che devono essere arrestate.
  • 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:

  1. Controlla my-queue ogni 30 secondi.
  2. Se la lunghezza della coda è uguale a 0, torna a (1).
  3. Se la lunghezza della coda è > 0, ridimensiona l'app a 1.
  4. Se la lunghezza della coda è 50, calcola desiredReplicas = ceil(50/5) = 10.
  5. Ridimensiona l'app a min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
  6. Torna a (1).

Se l'app è stata ridimensionata fino al numero massimo di repliche pari a 20, il ridimensionamento segue gli stessi passaggi precedenti. La riduzione delle prestazioni si verifica solo se la condizione è stata soddisfatta per 300 secondi (finestra di stabilizzazione per la riduzione delle prestazioni). 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 costi per l'utilizzo quando un'applicazione viene ridimensionata a zero. Per altre informazioni sui prezzi, vedere Fatturazione 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 in App contenitore di Azure.

Limitazioni note

  • Il ridimensionamento verticale non è supportato.

  • Le quantità di replica sono un valore di destinazione, non una garanzia.

  • Se si usano actor Dapr per gestire gli stati, tenere presente che il ridimensionamento a zero non è supportato. Dapr usa actor virtuali per gestire le chiamate asincrone, di conseguenza la rappresentazione in memoria non è associata alla relativa identità o durata.

Passaggi successivi