Condividi tramite

Impostare le regole di ridimensionamento in App contenitore di Azure

  • Articolo

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

Le regole di scalabilità di App contenitore 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, è necessario creare un segreto nell'array di secrets dell'app contenitore. Il valore del segreto viene usato nell'array auth della regola di scala.

Gli scaler 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.

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

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

  3. Nel modello ARM, per ogni segreto:

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

    2. Aggiungere una voce all'array di auth della regola di scala.

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

      2. Impostare il valore della proprietà secretRef sul nome della proprietà key di secretTargetRef.

    {
  ...
  "resources": {
    ...
    "properties": {
      ...
      "configuration": {
        ...
        "secrets": [
          {
            "name": "connection-string-secret",
            "value": "<SERVICE_BUS_CONNECTION_STRING>"
          }
        ]
      },
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [
            {
              "name": "azure-servicebus-queue-rule",
              "custom": {
                "type": "azure-servicebus",
                "metadata": {
                  "queueName": "my-queue",
                  "namespace": "service-bus-namespace",
                  "messageCount": "5"
                },
                "auth": [
                  {
                    "secretRef": "connection-string-secret",
                    "triggerParameter": "connection"
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
}

    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.

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 di ARM seguente passa l'identità gestita basata sul sistema per l'autenticazione per un scaler di code di Azure.

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

Per altre informazioni sull'uso dell'identità gestita assegnata dall'utente, vedere Identità gestita.

  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

Le regole di scalabilità di App contenitore 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 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à.

Uno scaler 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à dell'app contenitore.

  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"

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'app contenitore con un'identità gestita assegnata dall'utente e la usa per eseguire l'autenticazione per un scaler code di Azure.

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

Sostituire i segnaposto con i valori.

  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

Le regole di scalabilità di App contenitore 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

  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.

Uso dell'identità gestita

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

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

Gestire i segreti