17.5. À propos du CR ClusterGroupUpgrade
Le Topology Aware Lifecycle Manager (TALM) construit le plan de remédiation à partir de la CR ClusterGroupUpgrade pour un groupe de clusters. Vous pouvez définir les spécifications suivantes dans un CR ClusterGroupUpgrade:
- Clusters dans le groupe
-
Blocage des CR
ClusterGroupUpgrade - Liste des politiques gérées applicables
- Nombre de mises à jour simultanées
- Mises à jour des canaris applicables
- Actions à effectuer avant et après la mise à jour
- Calendrier de mise à jour
Vous pouvez contrôler l'heure de début d'une mise à jour en utilisant le champ enable dans le CR ClusterGroupUpgrade. Par exemple, si vous avez une fenêtre de maintenance programmée de quatre heures, vous pouvez préparer un CR ClusterGroupUpgrade avec le champ enable défini sur false.
Vous pouvez définir le délai d'attente en configurant le paramètre spec.remediationStrategy.timeout comme suit :
spec
remediationStrategy:
maxConcurrency: 1
timeout: 240
spec
remediationStrategy:
maxConcurrency: 1
timeout: 240
Vous pouvez utiliser l'adresse batchTimeoutAction pour déterminer ce qui se passe si une mise à jour échoue pour un cluster. Vous pouvez spécifier continue pour ignorer le cluster défaillant et continuer à mettre à jour les autres clusters, ou abort pour arrêter la remédiation des politiques pour tous les clusters. Une fois le délai écoulé, TALM supprime toutes les politiques enforce pour s'assurer qu'aucune autre mise à jour n'est effectuée sur les clusters.
Pour appliquer les modifications, vous définissez le champ enabled sur true.
Pour plus d'informations, voir la section "Application des stratégies de mise à jour aux clusters gérés".
Au fur et à mesure que TALM remédie aux politiques vers les clusters spécifiés, le CR ClusterGroupUpgrade peut signaler des statuts vrais ou faux pour un certain nombre de conditions.
Une fois que TALM a terminé la mise à jour d'un cluster, le cluster n'est plus mis à jour sous le contrôle du même CR ClusterGroupUpgrade. Vous devez créer un nouveau CR ClusterGroupUpgrade dans les cas suivants :
- Lorsque vous devez à nouveau mettre à jour le cluster
-
Lorsque le cluster devient non conforme à la politique
informaprès avoir été mis à jour
17.5.1. Sélection des grappes Copier lienLien copié sur presse-papiers!
TALM construit un plan de remédiation et sélectionne les clusters en fonction des champs suivants :
-
Le champ
clusterLabelSelectorspécifie les étiquettes des grappes que vous souhaitez mettre à jour. Il s'agit d'une liste de sélecteurs d'étiquettes standard provenant dek8s.io/apimachinery/pkg/apis/meta/v1. Chaque sélecteur de la liste utilise soit des paires de valeurs d'étiquettes, soit des expressions d'étiquettes. Les correspondances de chaque sélecteur sont ajoutées à la liste finale des grappes avec les correspondances des champsclusterSelectoretcluster. -
Le champ
clustersspécifie une liste de grappes à mettre à jour. -
Le champ
canariesspécifie les clusters pour les mises à jour canari. -
Le champ
maxConcurrencyindique le nombre de grappes à mettre à jour dans un lot.
Vous pouvez utiliser les champs clusters, clusterLabelSelector, et clusterSelector ensemble pour créer une liste combinée de clusters.
Le plan de remédiation commence par les clusters listés dans le champ canaries. Chaque grappe canarienne forme un lot à grappe unique.
Exemple de ClusterGroupUpgrade CR avec l'activation de field réglée sur false
- 1
- Définit la liste des grappes à mettre à jour.
- 2
- Le champ
enableest défini surfalse. - 3
- Répertorie l'ensemble des politiques définies par l'utilisateur pour remédier à la situation.
- 4
- Définit les spécificités des mises à jour de la grappe.
- 5
- Définit les clusters pour les mises à jour canari.
- 6
- Définit le nombre maximal de mises à jour simultanées dans un lot. Le nombre de lots de remédiation est le nombre de clusters canaris, plus le nombre de clusters, à l'exception des clusters canaris, divisé par la valeur maxConcurrency. Les clusters qui sont déjà conformes à toutes les politiques gérées sont exclus du plan de remédiation.
- 7
- Affiche les paramètres de sélection des grappes.
- 8
- Contrôle ce qui se passe en cas de dépassement du délai d'exécution d'un lot. Les valeurs possibles sont
abortoucontinue. Si aucune valeur n'est spécifiée, la valeur par défaut estcontinue. - 9
- Affiche des informations sur l'état des mises à jour.
- 10
- La condition
ClustersSelectedmontre que toutes les grappes sélectionnées sont valides. - 11
- La condition
Validatedmontre que toutes les grappes sélectionnées ont été validées.
Toute défaillance au cours de la mise à jour d'une grappe canarienne interrompt le processus de mise à jour.
Lorsque le plan de remédiation est créé avec succès, vous pouvez définir le champ enable sur true et TALM commence à mettre à jour les clusters non conformes avec les politiques gérées spécifiées.
Vous ne pouvez modifier les champs spec que si le champ enable du CR ClusterGroupUpgrade est défini sur false.
17.5.2. Valider Copier lienLien copié sur presse-papiers!
TALM vérifie que toutes les politiques gérées spécifiées sont disponibles et correctes, et utilise la condition Validated pour signaler l'état et les raisons comme suit :
trueLa validation est terminée.
falseLes politiques sont manquantes ou invalides, ou une image de plate-forme invalide a été spécifiée.
17.5.3. Mise en cache préalable Copier lienLien copié sur presse-papiers!
Les clusters peuvent avoir une bande passante limitée pour accéder au registre des images de conteneurs, ce qui peut entraîner un dépassement de délai avant que les mises à jour ne soient terminées. Sur les clusters OpenShift à nœud unique, vous pouvez utiliser la mise en cache préalable pour éviter ce problème. La mise en cache préalable de l'image de conteneur commence lorsque vous créez un CR ClusterGroupUpgrade avec le champ preCaching défini sur true.
TALM utilise la condition PrecacheSpecValid pour signaler les informations d'état comme suit :
trueLa spécification relative à la mise en cache préalable est valide et cohérente.
falseLa spécification relative à la mise en cache préalable est incomplète.
TALM utilise la condition PrecachingSucceeded pour signaler les informations d'état comme suit :
trueTALM a terminé le processus de pré-mise en cache. Si le pré-caching échoue pour un cluster, la mise à jour échoue pour ce cluster mais se poursuit pour tous les autres clusters. Un message vous informe de l'échec de la mise en cache pour l'un des clusters.
falseLa mise en cache est toujours en cours pour un ou plusieurs clusters ou a échoué pour tous les clusters.
Pour plus d'informations, voir la section "Using the container image pre-cache feature".
17.5.4. Création d'une sauvegarde Copier lienLien copié sur presse-papiers!
Pour OpenShift à nœud unique, TALM peut créer une sauvegarde d'un déploiement avant une mise à jour. Si la mise à jour échoue, vous pouvez récupérer la version précédente et restaurer un cluster à un état fonctionnel sans nécessiter un reprovisionnement des applications. Pour utiliser la fonctionnalité de sauvegarde, vous devez d'abord créer un CR ClusterGroupUpgrade avec le champ backup défini sur true. Pour garantir que le contenu de la sauvegarde est à jour, la sauvegarde n'est pas effectuée tant que vous n'avez pas défini le champ enable dans le CR ClusterGroupUpgrade sur true.
TALM utilise la condition BackupSucceeded pour signaler l'état et les raisons comme suit :
trueLa sauvegarde est terminée pour tous les clusters ou l'exécution de la sauvegarde s'est terminée mais a échoué pour un ou plusieurs clusters. Si la sauvegarde échoue pour un cluster, la mise à jour échoue pour ce cluster mais se poursuit pour tous les autres clusters.
falseLa sauvegarde est toujours en cours pour un ou plusieurs clusters ou a échoué pour tous les clusters.
Pour plus d'informations, voir la section "Création d'une sauvegarde des ressources du cluster avant la mise à niveau".
17.5.5. Mise à jour des grappes Copier lienLien copié sur presse-papiers!
TALM applique les politiques en suivant le plan de remédiation. L'application des politiques pour les lots suivants commence immédiatement après que tous les clusters du lot en cours sont conformes à toutes les politiques gérées. Si le lot s'arrête, TALM passe au lot suivant. La valeur du délai d'attente d'un lot est le champ spec.timeout divisé par le nombre de lots dans le plan de remédiation.
TALM utilise la condition Progressing pour signaler l'état et les raisons comme suit :
trueTALM remédie aux politiques non conformes.
falseLa mise à jour n'est pas en cours. Les raisons possibles sont les suivantes :
- Tous les clusters sont conformes à toutes les politiques gérées.
- La mise à jour a été interrompue car la remédiation de la politique a pris trop de temps.
- Les CR bloquants sont absents du système ou n'ont pas encore été achevés.
-
Le CR
ClusterGroupUpgraden'est pas activé. - La sauvegarde est toujours en cours.
Les politiques gérées s'appliquent dans l'ordre dans lequel elles sont listées dans le champ managedPolicies du CR ClusterGroupUpgrade. Une politique gérée est appliquée aux grappes spécifiées à la fois. Lorsqu'un cluster est conforme à la politique actuelle, la politique gérée suivante lui est appliquée.
Exemple ClusterGroupUpgrade CR dans l'état Progressing
- 1
- Les champs
Progressingmontrent que TALM est en train de remédier aux politiques.
17.5.6. Mise à jour du statut Copier lienLien copié sur presse-papiers!
TALM utilise la condition Succeeded pour signaler l'état et les raisons comme suit :
trueTous les clusters sont conformes aux politiques de gestion spécifiées.
falseLa remédiation de la politique a échoué parce qu'il n'y avait pas de clusters disponibles pour la remédiation, ou parce que la remédiation de la politique a pris trop de temps pour l'une des raisons suivantes :
- Le lot actuel contient des mises à jour canaris et le cluster dans le lot ne respecte pas toutes les politiques gérées dans le délai d'expiration du lot.
-
Les clusters n'ont pas respecté les politiques gérées dans la limite de la valeur
timeoutspécifiée dans le champremediationStrategy.
Exemple ClusterGroupUpgrade CR dans l'état Succeeded
- 2
- Dans les champs
Progressing, l'état estfalsecar la mise à jour est terminée ; les clusters sont conformes à toutes les politiques gérées. - 3
- Les champs
Succeededindiquent que les validations se sont déroulées avec succès. - 1
- Le champ
statuscomprend une liste de clusters et leurs statuts respectifs. Le statut d'un groupe peut êtrecompleteoutimedout.
Exemple ClusterGroupUpgrade CR dans l'état timedout
17.5.7. Blocage des CR de ClusterGroupUpgrade Copier lienLien copié sur presse-papiers!
Vous pouvez créer plusieurs CR ClusterGroupUpgrade et contrôler leur ordre d'application.
Par exemple, si vous créez ClusterGroupUpgrade CR C qui bloque le démarrage de ClusterGroupUpgrade CR A, ClusterGroupUpgrade CR A ne peut pas démarrer tant que le statut de ClusterGroupUpgrade CR C ne devient pas UpgradeComplete.
Un CR ClusterGroupUpgrade peut avoir plusieurs CR bloquants. Dans ce cas, tous les CR bloquants doivent être terminés avant que la mise à niveau du CR actuel puisse commencer.
Conditions préalables
- Installez le gestionnaire de cycle de vie Topology Aware (TALM).
- Provisionner un ou plusieurs clusters gérés.
-
Connectez-vous en tant qu'utilisateur disposant des privilèges
cluster-admin. - Créer des stratégies RHACM dans le cluster hub.
Procédure
Enregistrez le contenu des CR
ClusterGroupUpgradedans les fichierscgu-a.yaml,cgu-b.yamletcgu-c.yaml.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Définit les CR de blocage. La mise à jour de
cgu-ane peut pas commencer tant quecgu-cn'est pas terminé.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La mise à jour de
cgu-bne peut pas commencer tant quecgu-an'est pas terminée.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La mise à jour
cgu-cne comporte pas de CR bloquante. Le TALM lance la mise à jourcgu-clorsque le champenableest défini surtrue.
Créez les CR
ClusterGroupUpgradeen exécutant la commande suivante pour chaque CR concerné :oc apply -f <name>.yaml
$ oc apply -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Lancez le processus de mise à jour en exécutant la commande suivante pour chaque CR concerné :
oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \ --type merge -p '{"spec":{"enable":true}}'$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \ --type merge -p '{"spec":{"enable":true}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Les exemples suivants montrent des CR
ClusterGroupUpgradeoù le champenableest remplacé partrue:Exemple pour
cgu-aavec des CR bloquantsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Affiche la liste des CR bloquants.
Exemple pour
cgu-bavec des CR bloquantsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Affiche la liste des CR bloquants.
Exemple pour
cgu-cavec des CR bloquantsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La mise à jour du site
cgu-cne comporte pas de CR bloquants.