Mise à jour propagée NGroups
Introduction
Au fur et à mesure de l'évolution des besoins, vous devrez peut-être mettre à jour vos NGroups et ses groupes de conteneurs (GC).
Deux modes de mise à jour sont disponibles pour la mise à jour d'un NGroups – Manuel (option par défaut) et Roulant.
Dans la mise à jour propagée (RU), il existe 2 options : mise à jour sur place et remplacement. La RU de remplacement est l’option par défaut.
Ce document décrit en détail les RU. La mise à jour manuelle est abordée dans le lien de documentation NGroups ici.
Description de la fonctionnalité
Prenons un exemple de base de la mise à jour d’une référence de profil CG de cgprofile1 vers cgprofile2.
Mise à jour propagée sur place
Avec la RU sur place, lorsque nous mettons à jour la référence vers cgprofile2 et émettons une commande UPDATE NGroups, lesCG existants sont mis à jour avec cgprofile2. La mise à jour des groupes de conteneurs existants se fait par petits lots (et pas tous en même temps). Cela garantit un impact minimal sur votre charge de travail, car seul un petit pourcentage de groupes de conteneurs peut être indisponible durant la mise à jour.
Nous pouvons configurer la taille du lot et d’autres paramètres associés du mode de mise à jour propagée avec l’API NGroups.
Étant donné que la RU sur place met à jour les CG existants, certaines limitations sont imposées par Azure Container Instances (ACI) aux propriétés des CG.
Consultez les limitations d’ACI concernant la mise à des CG. Consultez également ici les propriétés sur les CG qui nécessitent une suppression (par rapport à une mise à jour).
Mise à jour propagée de remplacement
Avec la RU de remplacement, lorsque nous mettons à jour la référence vers cgprofile2 et émettons une commande UPDATE NGroups, de nouveaux CG sont créés avec cgprofile2. Les CG existants avec cgprofile1 sont supprimés. Cette création et cette suppression se produisent en petits lots (et pas tous en même temps). Cela garantit un impact minimal sur votre charge de travail, car seul un petit pourcentage des CG est affecté pendant la mise à jour.
Comme la RU sur place, nous pouvons configurer la taille du lot et d’autres paramètres associés du mode de mise à jour propagée avec l’API NGroups.
Étant donné que la RU de remplacement crée de nouveaux CG, il existe moins de limitations appliquées par ACI. Par conséquent, l'option de remplacement de l'EF est plus puissante et constitue l'option par défaut lorsqu'un client choisit l'EF.
Utilisation
Déclenchement d’une mise à jour propagée
La mise à jour propagée est déclenchée lorsqu’un appel PUT est effectué sur le NGroups et que le profil CG dans l’appel PUT est différent du profil CG actuellement référencé dans le NGroups.
Le NGroups regroupe ensuite automatiquement les instances en lots et met à jour un lot à la fois. Le paramètre maxBatchPercent détermine la taille du lot.
Mise à jour d’un lot
Une mise à jour sur place invoque un appel CG PUT pour mettre à jour chaque CG du lot.
Une mise à jour de remplacement invoque un appel CG PUT pour créer de nouveaux CG et supprimer les CG existants du lot. Il existe une correspondance 1:1 entre les CG créés et les CG en cours de suppression. Toutefois, les noms CG seront différents.
Si un nombre suffisant de CG dans le lot fournissent des signaux sains après la période pauseTimeBetweenBatches, le NGroups démarre automatiquement le lot suivant pour la mise à jour. Sinon, il arrête le déploiement. Le paramètre maxUnhealthyPercent spécifie le nombre total de GC non sains, tandis que le paramètre maxUnhealthyUpdatedPercent spécifie le nombre total de CG non sains après la mise à jour.
Voici un exemple pour émettre une requête de mise à jour propagée vers 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"
}
}
]
}
}
Si la version de l’image est définie sur la balise la plus récente pour les images conteneur dans le profil du CG, NGroups récupère automatiquement la dernière version de l’image pendant la RU. Pour éviter tout comportement inattendu dans votre application, il est recommandé de ne pas utiliser la dernière balise pour les images. Utilisez plutôt des versions spécifiques.
Remarque
Pour utiliser la RU de remplacement, définissez la balise « rollingupdate.replace.enabled : true » pour la ressource NGroups. Cette balise est temporaire et elle ne sera pas nécessaire à l’avenir.
“tags”: {
“rollingupdate.replace.enabled”: true
}
Obtention de l’état d’une mise à jour propagée en cours d’exécution
Pour obtenir l’état le plus récent de votre mise à jour propagée, vous pouvez utiliser cette API REST :
GET /subscriptions/{subscriptionId}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/NGroups/{{ngroupsName}}/latestRollingUpdate
Cette opération renvoie une réponse contenant des informations pertinentes sur l'EF.
Annulation d’une mise à jour propagée
Pour annuler une mise à jour propagée, utilisez l’API suivante. Une fois annulée, la RU ne peut pas être reprise/redémarrée. Une nouvelle RU doit être déclenchée.
POST /subscriptions/{subscriptionId}/resourceGroups/{{rgName}}/providers/Microsoft.ContainerInstance/NGroups/{{ngroupsName}}/cancelRollingUpdate
Vous n’avez pas besoin de fournir un corps de requête lors de l’appel de cette API.
Limite d’un lot dans une mise à jour propagée
Les CG d’un lot spécifique dans une RU ne franchissent pas une limite de modèle d’erreur. Un modèle d’erreur représente une combinaison zone/domaine d’erreur (FD). Par exemple, zone 1 / FD 0 est une limite de modèle d’erreur, zone 1 / FD 1 est une autre limite de modèle d’erreur, et zone 2 / FD 0 est encore une autre limite de modèle d’erreur.
Si un client dispose d’un NGroups à plusieurs zones configuré avec trois zones, un lot est limité aux CG appartenant à une seule zone au maximum. Un lot ne se compose jamais de CG répartis entre plusieurs zones.
Si un client dispose d’une configuration NGroups à plusieurs zones et plusieurs FD, un lot se compose toujours de CG appartenant à un seul FD dans une seule zone au maximum.
Le NGroups conserve cette limite de modèle d’erreur dans un lot, même si le nombre de CG sélectionnés pour un lot est beaucoup moins élevé que le paramètre maxBatchPercent. Il reflète le fait que NGroups préfère les mises à jour sécurisées par rapport aux mises à jour plus rapides (et donc plus risquées).
La seule fois qu’une limite de modèle d’erreur est franchie est lorsque la RU sélectionne des CG non sains pour le premier lot. Dans ce lot, la RU tente de mettre à jour tous les CG non sains afin d’améliorer la disponibilité globale de NGroups. Par conséquent, lors de la mise à jour des CG non sains, la RU peut dépasser le paramètre maxBatchPercent.