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
inform
aprè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
clusterLabelSelector
spé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 champsclusterSelector
etcluster
. -
Le champ
clusters
spécifie une liste de grappes à mettre à jour. -
Le champ
canaries
spécifie les clusters pour les mises à jour canari. -
Le champ
maxConcurrency
indique 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
enable
est 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
abort
oucontinue
. 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
ClustersSelected
montre que toutes les grappes sélectionnées sont valides. - 11
- La condition
Validated
montre 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 :
true
La validation est terminée.
false
Les 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 :
true
La spécification relative à la mise en cache préalable est valide et cohérente.
false
La 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 :
true
TALM 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.
false
La 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 :
true
La 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.
false
La 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 :
true
TALM remédie aux politiques non conformes.
false
La 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
ClusterGroupUpgrade
n'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
Progressing
montrent 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 :
true
Tous les clusters sont conformes aux politiques de gestion spécifiées.
false
La 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
timeout
spécifiée dans le champremediationStrategy
.
Exemple ClusterGroupUpgrade
CR dans l'état Succeeded
- 2
- Dans les champs
Progressing
, l'état estfalse
car la mise à jour est terminée ; les clusters sont conformes à toutes les politiques gérées. - 3
- Les champs
Succeeded
indiquent que les validations se sont déroulées avec succès. - 1
- Le champ
status
comprend une liste de clusters et leurs statuts respectifs. Le statut d'un groupe peut êtrecomplete
outimedout
.
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
ClusterGroupUpgrade
dans les fichierscgu-a.yaml
,cgu-b.yaml
etcgu-c.yaml
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Définit les CR de blocage. La mise à jour de
cgu-a
ne peut pas commencer tant quecgu-c
n'est pas terminé.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La mise à jour de
cgu-b
ne peut pas commencer tant quecgu-a
n'est pas terminée.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La mise à jour
cgu-c
ne comporte pas de CR bloquante. Le TALM lance la mise à jourcgu-c
lorsque le champenable
est défini surtrue
.
Créez les CR
ClusterGroupUpgrade
en exécutant la commande suivante pour chaque CR concerné :oc apply -f <name>.yaml
$ oc apply -f <name>.yaml
Copy 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
ClusterGroupUpgrade
où le champenable
est remplacé partrue
:Exemple pour
cgu-a
avec des CR bloquantsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Affiche la liste des CR bloquants.
Exemple pour
cgu-b
avec des CR bloquantsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Affiche la liste des CR bloquants.
Exemple pour
cgu-c
avec des CR bloquantsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La mise à jour du site
cgu-c
ne comporte pas de CR bloquants.