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.
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.
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.
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 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.
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.
È 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:
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.
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.
Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA.
Nell'oggetto TriggerAuthentication trovare ogni secretTargetRef e il segreto associato.
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.
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.
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.
Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA. Identificare ogni voce secretTargetRef dell'oggetto TriggerAuthentication.
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.
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
Nell'app contenitore creare i segreti a cui si vuole fare riferimento.
Trovare l'oggetto TriggerAuthentication a cui fa riferimento la specifica ScaledObject KEDA. Identificare ogni voce secretTargetRef dell'oggetto TriggerAuthentication.
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
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.
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, torna a (1).
Se la lunghezza della coda è > 0, ridimensiona 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))
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.
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.
Questo modulo illustra il concetto di revisioni in App Contenitore di Azure e illustra le opzioni per la gestione del ciclo di vita delle applicazioni. Vengono inoltre illustrate le opzioni di ridimensionamento e le impostazioni di ingresso, inclusa la suddivisione del traffico per le app Azure Container.