NGroups Rolling Update
Introduzione
Man mano che cambiano i requisiti, potrebbe essere necessario aggiornare i gruppi di gruppi di sicurezza di rete e i relativi gruppi di contenitori.
Sono disponibili due modalità di aggiornamento per l'aggiornamento di un gruppo di sicurezza di rete: manuale (opzione predefinita) e sequenza.
All'interno dell'aggiornamento in sequenza (UR) sono disponibili 2 opzioni: aggiornamento sul posto e aggiornamento sostituzione. Sostituisci UR è l'opzione predefinita.
Questo documento descrive in dettaglio le UR. L'aggiornamento manuale è illustrato nel collegamento alla documentazione NGroups qui.
Descrizione della funzionalità
Si consideri un esempio di base dell'aggiornamento di un riferimento al profilo CG da cgprofile1 a cgprofile2.
Aggiornamento in sequenza sul posto
Con le UR sul posto, quando aggiorniamo il riferimento a cgprofile2 ed esegui un comando UPDATE NGroups, i CG esistenti vengono aggiornati con cgprofile2. L'aggiornamento ai gruppi di disponibilità esistenti avviene in batch di piccole dimensioni (e non tutti contemporaneamente). Garantisce un impatto minimo sul carico di lavoro, perché solo una piccola percentuale di gruppi di disponibilità potrebbe non essere disponibile durante l'aggiornamento.
È possibile configurare le dimensioni del batch e altre impostazioni relative alla modalità di aggiornamento in sequenza con l'API NGroups.
Poiché le UR sul posto aggiornano i CG esistenti, esistono alcune limitazioni alle proprietà CG applicate Istanze di Azure Container (ACI).
Vedere le limitazioni di ACI relative all'aggiornamento dei gruppi di disponibilità. Vedere anche qui per le proprietà nei gruppi di disponibilità che richiedono un'eliminazione (rispetto a un aggiornamento).
Sostituisci aggiornamento in sequenza
Con replace UR, quando aggiorniamo il riferimento a cgprofile2 ed esegui un comando UPDATE NGroups, vengono creati nuovi CG con cgprofile2. I gruppi di disponibilità esistenti con cgprofile1 vengono eliminati. Questa creazione e eliminazione avviene in piccoli batch (e non tutti contemporaneamente). Garantisce un impatto minimo sul carico di lavoro, perché durante l'aggiornamento viene interessata solo una piccola percentuale di gruppi di disponibilità.
Analogamente alle UR sul posto, è possibile configurare le dimensioni del batch e altre impostazioni correlate della modalità di aggiornamento in sequenza con l'API NGroups.
Poiché replace UR crea nuovi CG, esistono meno limitazioni applicate dall'ACI. Di conseguenza, sostituire LE UR è un'opzione più potente ed è l'opzione predefinita quando un cliente seleziona LE UR.
Utilizzo
Attivazione di un aggiornamento in sequenza
L'aggiornamento in sequenza viene attivato quando viene effettuata una chiamata PUT NGroups e il profilo CG nella chiamata PUT è diverso dal profilo CG attualmente a cui si fa riferimento nei NGroup.
I gruppi di sicurezza di rete raggruppano quindi automaticamente le istanze in batch e aggiornano un batch alla volta. Il parametro maxBatchPercent determina le dimensioni del batch.
Aggiornamento di un batch
Un aggiornamento sul posto richiama una chiamata CG PUT per aggiornare ogni CG del batch.
Un aggiornamento di sostituzione richiama una chiamata CG PUT per creare nuovi CG ed eliminare i CG esistenti del batch. Esiste una corrispondenza 1:1 tra i gruppi di disponibilità creati e i gruppi di disponibilità eliminati. Tuttavia, i nomi CG saranno diversi.
Se un numero sufficiente di gruppi di disponibilità nel batch fornisce segnali integri dopo il periodo pauseTimeBetweenBatches, NGroups avvia automaticamente il batch successivo per l'aggiornamento. In caso contrario, arresta l'implementazione. Il parametro maxUnhealthyPercent specifica il numero totale di gruppi di disponibilità non integri, mentre il parametro maxUnhealthyUpdatedPercent specifica il numero totale di CG non integri dopo l'aggiornamento.
Di seguito è riportato un esempio per eseguire una richiesta di aggiornamento in sequenza a NGroups:
{
"location": "{{location}}",
"properties": {
"updateProfile": {
"updateMode": "Rolling",
"rollingUpdateProfile": {
// Maximum percentage of total CGs which can be updated
// simultaneously by rolling update in one batch.
“maxBatchPercent”: “10”, // optional, defaults to 20%
// Maximum percentage of the total CGs across the whole NGroup
// that can be unhealthy at a time either by rolling update or health
// checks by liveness probes. If there are more unhealthy CGs than this,
// the current rolling update is marked as failed.
// This check is a prerequisite to start any batch.
“maxUnhealthyPercent”: “10”, // optional, defaults to 20%
// Maximum percentage of the updated CGs which can be in unhealthy state
// after each batch is updated. If there are more unhealthy CGs than this,
// the current rolling update is marked as failed.
“maxUnhealthyUpdatedPercent”: 10, // optional, defaults to 20%
// The wait time between batches after completing one batch of the rolling
// update and before starting the next batch. The time duration should
// be specified in ISO 8601 format for duration.
"pauseTimeBetweenBatches": "PT2M", // optional, defaults to PT1M
// A nullable boolean property. Default is null
// Sets the mode to either in-place RU (when true) or replace (default) RU.
“inPlaceUpdate”: null/false/true
}
},
"containerGroupProfiles": [
{
"resource": {
"id": "/subscriptions/{{subId}}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/containerGroupProfiles/cgp1"
}
}
]
}
}
Se la versione dell'immagine è impostata sul tag più recente per le immagini del contenitore all'interno del profilo CG, NGroups preleva automaticamente la versione più recente dell'immagine durante le UR. Per evitare comportamenti imprevisti nell'applicazione, è consigliabile non usare il tag più recente per le immagini. Usare invece versioni specifiche.
Nota
Per usare replace UR, impostare il tag "rollingupdate.replace.enabled: true" per la risorsa NGroups. Questo tag è temporaneo e non sarà necessario in futuro.
“tags”: {
“rollingupdate.replace.enabled”: true
}
Recupero dello stato di un aggiornamento in sequenza in esecuzione
Per ottenere lo stato più recente dell'aggiornamento in sequenza, è possibile usare questa API REST:
GET /subscriptions/{subscriptionId}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/NGroups/{{ngroupsName}}/latestRollingUpdate
Viene restituita una risposta contenente informazioni pertinenti sulle UR.
Annullamento di un aggiornamento in sequenza
Per annullare un aggiornamento in sequenza, usare l'API seguente. Dopo l'annullamento, non è possibile riprendere o riavviare le UR. È necessario attivare una nuova unità richiesta.
POST /subscriptions/{subscriptionId}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/NGroups/{{ngroupsName}}/cancelRollingUpdate
Non è necessario fornire un corpo della richiesta quando si chiama questa API.
Limite di un batch in un aggiornamento in sequenza
I gruppi di disponibilità di un batch specifico in una UR non superano un limite del modello di errore. Un modello di errore rappresenta una combinazione di zona/dominio di errore (FD). Ad esempio, la zona 1/FD 0 è un limite del modello di errore, la zona 1/ FD 1 è un altro limite del modello di errore e la zona 2/ FD 0 è ancora un altro limite del modello di errore.
Se un cliente dispone di un gruppo di sicurezza di rete multi-zona configurato con tre zone, un batch è limitato ai gruppi di disponibilità appartenenti a una sola zona al massimo. Un batch non è mai costituito da gruppi di disponibilità distribuiti in più zone.
Se un cliente ha una configurazione NGroup multi-zonale e multi-FD, un batch è comunque costituito da gruppi di disponibilità appartenenti a un solo fd in una singola zona al massimo.
NGroups mantiene questo limite del modello di errore in un batch, anche quando il numero di gruppi di disponibilità selezionati per un batch è molto inferiore all'impostazione maxBatchPercent. Riflette che NGroup preferisce aggiornamenti sicuri rispetto a aggiornamenti più veloci (e quindi più rischiosi).
L'unica volta che viene superato un limite del modello di errore quando l'UR seleziona i gruppi di controllo non integri per il primo batch. In questo batch, le UR tentano di aggiornare tutti i gruppi di disponibilità non integri per migliorare la disponibilità complessiva di NGroup. Di conseguenza, quando si aggiornano gruppi di controllo non integri, le UR possono superare l'impostazione maxBatchPercent.