Impostare le regole di ridimensionamento nelle app Azure Container

App Azure Container gestisce il ridimensionamento orizzontale automatico 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 modifiche delle revisioni.

I processi di App contenitore basate su eventi usano 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 Le repliche massime configurabili sono 300 in portale di Azure e 1.000 nell'interfaccia della riga di comando di Azure.
    Numero massimo di repliche per revisione 10 1 Le repliche massime configurabili sono 300 in portale di Azure e 1.000 nell'interfaccia della riga di comando di Azure.
  • 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 della scalabilità spiega come vengono prese decisioni sulla scalabilità.

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

  • Non vengono addebitati addebiti per l'utilizzo se l'app contenitore viene ridimensionata a zero.
  • Le repliche che non elaborano, ma rimangono in memoria potrebbero essere fatturate a una velocità di inattività inferiore. Per altre informazioni, vedereFatturazione.
  • Se si vuole 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.
  • Personalizzato: basato su 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 ridimensionare una volta soddisfatta la prima condizione di tutte le regole.

HTTP

Con una regola di ridimensionamento HTTP, è possibile controllare 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. 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 ridimensionata a zero. La proprietà di ridimensionamento è impostata su 100 richieste simultanee al secondo.

Esempio

La http sezione definisce una regola di scalabilità HTTP.

Proprietà Scale 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 ad aggiungere al pool fino all'importo 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 --scale-rule-http-concurrency parametro nei create comandi 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 ad aggiungere al pool fino all'importo 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 distribuzione.

  4. Selezionare la scheda Scala .

  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 di regola.

  8. Nell'elenco a discesa Tipo selezionare Scalabilità 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 la scalabilità 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 il numero di istanze fino a cinque repliche e può passare a zero. La soglia di ridimensionamento è impostata su 100 connessioni simultanee al secondo.

Esempio

La tcp sezione definisce una regola di scalabilità TCP.

Proprietà Scale 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 all'importo 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 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 all'importo 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 \
  --scale-rule-name azure-tcp-rule \
  --scale-rule-type tcp \
  --scale-rule-tcp-concurrency 100

Non supportato nella 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 di App contenitore in base a qualsiasi scaler KEDA basato su ScaledObject con queste impostazioni predefinite:

Impostazioni predefinite Secondi
Intervallo di polling 30
Periodo di raffreddamento 300

Per i processi di App contenitore basate su eventi, è possibile creare una regola di ridimensionamento personalizzata basata su qualsiasi scaler KEDA basato 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 di scala KEDA basata su ScaledObject.

Per l'autenticazione, i parametri di autenticazione del scaler KEDA convertno in segreti di App contenitore.

La procedura seguente illustra come convertire un scaler KEDA in una regola di scalabilità di app contenitore. Questo frammento di codice è un estratto di un modello di Resource Manager per mostrare dove ogni sezione rientra 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 di contesto sul modo in cui gli esempi seguenti si adattano al modello di Resource Manager.

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

  1. Nella specifica del scaler KEDA trovare il type valore.

    triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue
        namespace: service-bus-namespace
        messageCount: "5"
    
  2. Nel modello di Resource Manager 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"
          }
        }
      }
    ]
    ...
    
  3. Nella specifica del scaler KEDA trovare i metadata valori.

    triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue
        namespace: service-bus-namespace
        messageCount: "5"
    
  4. Nel modello di Resource Manager 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

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

Nota

Le regole di scalabilità di 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 KEDA ScaledObject .

  2. Dalla specifica KEDA trovare ogni secretTargetRefTriggerAuthentication oggetto e il relativo 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 Resource Manager aggiungere tutte le voci alla auth matrice della regola di scalabilità.

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

    2. Impostare il valore della triggerParameter proprietà sul valore della TriggerAuthenticationproprietà della proprietà .key

    3. Impostare il valore della secretRef proprietà sul nome del segreto 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"
                      }
                    ]
                  }
                }
              ]
            }
          }
        }
      }
    }
    

    Alcuni scaler supportano i metadati con il FromEnv suffisso per fare riferimento a un valore in una variabile di ambiente. App contenitore esamina il primo contenitore elencato nel modello di Resource Manager per la variabile di ambiente.

    Per altre informazioni sulla sicurezza, vedere la sezione considerazioni.

  1. Nella specifica del scaler KEDA trovare il type valore.

    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 --scale-rule-type parametro sul valore della specifica type .

    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. Nella specifica del scaler KEDA trovare i metadata valori.

    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 --scale-rule-metadata parametro 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 scaler KEDA supporta l'uso di 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.

Nota

Le regole di scalabilità di 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 KEDA ScaledObject . Identificare ogni secretTargetRefTriggerAuthentication oggetto.

    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 secretTargetRef proprietà.

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

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

    2. Creare una voce di autenticazione con il --scale-rule-auth parametro . 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 distribuzione.

  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 di regola.

  8. Nell'elenco a discesa Tipo selezionare Personalizzato.

  9. Nella specifica del scaler KEDA trovare il type valore.

    triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue
        namespace: service-bus-namespace
        messageCount: "5"
    
  10. Nella casella Tipo di regola personalizzata immettere il valore di scalertype.

  11. Nella specifica del scaler KEDA trovare i metadata valori.

    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 metadati della specifica KEDA ScaledObject .

Autenticazione

Un scaler KEDA supporta l'uso di 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.

Nota

Le regole di scalabilità di 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 KEDA ScaledObject . Identificare ogni secretTargetRefTriggerAuthentication oggetto.

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

Regola di scalabilità predefinita

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

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 abilita l'ingresso. Se l'ingresso è disabilitato e non si definisce una minReplicas regola di scalabilità personalizzata o , l'app contenitore verrà ridimensionata a zero e non sarà possibile avviare il backup.

Comportamento della scalabilità

Il comportamento di ridimensionamento ha le impostazioni predefinite seguenti:

Parametro Valore
Intervallo di polling 30 secondi
Periodo di raffreddamento 300 secondi
Finestra di stabilizzazione con scalabilità orizzontale 0 secondi
Finestra di stabilizzazione ridimensionamento 300 secondi
Aumentare le prestazioni 1, 4, 100% di corrente
Passaggio di riduzione 100% dell'attuale
Algoritmo di ridimensionamento desiredReplicas = ceil(currentMetricValue / targetMetricValue)
  • L'intervallo di polling è la frequenza con cui le origini eventi vengono sottoposte a query da KEDA. Questo valore non si applica alle regole di scalabilità HTTP e TCP.
  • Il periodo di raffreddamento è il periodo di tempo trascorso l'ultimo evento osservato prima che l'applicazione si riduce al numero minimo di repliche.
  • La finestra di stabilizzazione con scalabilità orizzontale è il tempo di attesa prima di eseguire una decisione di aumento delle prestazioni dopo che sono state soddisfatte le condizioni di aumento delle prestazioni.
  • L'intervallo di stabilizzazione con riduzione delle prestazioni è il tempo di attesa prima di eseguire una decisione di riduzione quando sono state soddisfatte le condizioni di riduzione delle prestazioni.
  • 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, il 100% delle repliche che devono essere arrestate vengono rimosse.
  • L'algoritmo di ridimensionamento è la formula usata per calcolare il numero di repliche desiderato corrente.

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

Con il ridimensionamento orizzontale dell'app, KEDA inizia con una coda vuota ed esegue i passaggi seguenti:

  1. Controllare my-queue ogni 30 secondi.
  2. Se la lunghezza della coda è uguale a 0, tornare a (1).
  3. Se la lunghezza della coda è > 0, ridimensionare l'app a 1.
  4. Se la lunghezza della coda è 50, calcolare desiredReplicas = ceil(50/5) = 10.
  5. Ridimensionare l'app in min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
  6. Tornare a (1).

Se l'app è stata ridimensionata fino al numero massimo di repliche pari a 20, il ridimensionamento passa attraverso gli stessi passaggi precedenti. La riduzione delle prestazioni si verifica solo se la condizione è stata 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 su 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 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 Fatturazione nelle app Azure Container.

  • È necessario abilitare la protezione dei dati per tutte le app .NET nelle app Contenitore di Azure. Per informazioni dettagliate, vedere Distribuzione e ridimensionamento di un'app ASP.NET Core in App Azure Container.

Limitazioni note

  • La scalabilità verticale non è supportata.

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

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

Passaggi successivi