21.10. Mise à jour des clusters gérés avec le Topology Aware Lifecycle Manager
Vous pouvez utiliser le Topology Aware Lifecycle Manager (TALM) pour gérer le cycle de vie du logiciel des clusters gérés par OpenShift Container Platform. TALM utilise les stratégies de Red Hat Advanced Cluster Management (RHACM) pour effectuer des modifications sur les clusters cibles.
21.10.1. Mise à jour des clusters dans un environnement déconnecté Copier lienLien copié sur presse-papiers!
Vous pouvez mettre à niveau les clusters gérés et les opérateurs des clusters gérés que vous avez déployés à l'aide de GitOps ZTP et de Topology Aware Lifecycle Manager (TALM).
21.10.1.1. Mise en place de l'environnement Copier lienLien copié sur presse-papiers!
TALM peut effectuer des mises à jour de la plateforme et de l'opérateur.
Vous devez mettre en miroir l'image de la plate-forme et les images de l'opérateur que vous souhaitez mettre à jour dans votre registre miroir avant de pouvoir utiliser TALM pour mettre à jour vos clusters déconnectés. Effectuez les étapes suivantes pour créer un miroir des images :
Pour les mises à jour de la plate-forme, vous devez effectuer les étapes suivantes :
Mettre en miroir le référentiel d'images OpenShift Container Platform souhaité. Assurez-vous que l'image de la plateforme souhaitée est mise en miroir en suivant la procédure " Mirroring the OpenShift Container Platform image repository " (Mise en miroir du référentiel d'images OpenShift Container Platform) dont le lien se trouve dans les Ressources supplémentaires. Enregistrez le contenu de la section
imageContentSources
dans le fichierimageContentSources.yaml
:Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enregistrez la signature de l'image de la plate-forme souhaitée qui a été mise en miroir. Vous devez ajouter la signature de l'image à la CR
PolicyGenTemplate
pour les mises à jour de la plate-forme. Pour obtenir la signature de l'image, procédez comme suit :Spécifiez le tag OpenShift Container Platform souhaité en exécutant la commande suivante :
oCP_RELEASE_NUMBER=<release_version>
oCP_RELEASE_NUMBER=<release_version>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Spécifiez l'architecture du serveur en exécutant la commande suivante :
aRCHITECTURE=<server_architecture>
aRCHITECTURE=<server_architecture>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Obtenez le résumé de l'image de la version de Quay en exécutant la commande suivante
DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
$ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Définissez l'algorithme de résumé en exécutant la commande suivante :
DIGEST_ALGO="${DIGEST%%:*}"
$ DIGEST_ALGO="${DIGEST%%:*}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Définissez la signature numérique en exécutant la commande suivante :
DIGEST_ENCODED="${DIGEST#*:}"
$ DIGEST_ENCODED="${DIGEST#*:}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Obtenez la signature de l'image à partir du site web mirror.openshift.com en exécutant la commande suivante :
SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
$ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enregistrez la signature de l'image dans le fichier
checksum-<OCP_RELEASE_NUMBER>.yaml
en exécutant les commandes suivantes :cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
$ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Préparer le graphique de mise à jour. Vous avez deux options pour préparer le graphique de mise à jour :
Utiliser le service de mise à jour OpenShift.
Pour plus d'informations sur la mise en place du graphe sur le hub cluster, voir Déployer l'opérateur pour OpenShift Update Service et Construire le conteneur init de données du graphe.
Faites une copie locale du graphe en amont. Hébergez le graphique de mise à jour sur un serveur
http
ouhttps
dans l'environnement déconnecté qui a accès au cluster géré. Pour télécharger le graphe de mise à jour, utilisez la commande suivante :curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.12 -o ~/upgrade-graph_stable-4.12
$ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.12 -o ~/upgrade-graph_stable-4.12
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Pour les mises à jour de l'opérateur, vous devez effectuer la tâche suivante :
- Mettre en miroir les catalogues de l'opérateur. Assurez-vous que les images d'opérateur souhaitées sont mises en miroir en suivant la procédure décrite dans la section "Mise en miroir des catalogues d'opérateur pour utilisation avec des clusters déconnectés".
21.10.1.2. Mise à jour de la plate-forme Copier lienLien copié sur presse-papiers!
Vous pouvez effectuer une mise à jour de la plate-forme avec le TALM.
Conditions préalables
- Installez le gestionnaire de cycle de vie Topology Aware (TALM).
- Mettre à jour ZTP avec la dernière version.
- Approvisionnez un ou plusieurs clusters gérés avec ZTP.
- Mettez en miroir le référentiel d'images souhaité.
-
Connectez-vous en tant qu'utilisateur disposant des privilèges
cluster-admin
. - Créer des stratégies RHACM dans le cluster hub.
Procédure
Créer un CR
PolicyGenTemplate
pour la mise à jour de la plateforme :Enregistrez le contenu suivant du CR
PolicyGenTemplate
dans le fichierdu-upgrade.yaml
.Exemple de
PolicyGenTemplate
pour la mise à jour de la plate-formeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Le CR
ConfigMap
contient la signature de l'image de la version souhaitée à mettre à jour. - 2
- Affiche la signature de l'image de la version d'OpenShift Container Platform souhaitée. Obtenez la signature à partir du fichier
checksum-${OCP_RELASE_NUMBER}.yaml
que vous avez enregistré en suivant les procédures de la section " Configuration de l'environnement ". - 3
- Affiche le dépôt miroir qui contient l'image OpenShift Container Platform souhaitée. Obtenez les miroirs à partir du fichier
imageContentSources.yaml
que vous avez enregistré en suivant les procédures de la section " Configuration de l'environnement ". - 4
- Indique le CR
ClusterVersion
à mettre à jour en amont. - 5
- Indique le CR
ClusterVersion
pour déclencher la mise à jour. Les champschannel
,upstream
, etdesiredVersion
sont tous nécessaires pour la mise en cache des images.
La CR
PolicyGenTemplate
génère deux politiques :-
La politique
du-upgrade-platform-upgrade-prep
prépare la mise à jour de la plate-forme. Elle crée le CRConfigMap
pour la signature d'image de version souhaitée, crée la source de contenu d'image du référentiel d'images de version en miroir et met à jour la version du cluster avec le canal de mise à jour souhaité et le graphique de mise à jour accessible par le cluster géré dans l'environnement déconnecté. -
La politique
du-upgrade-platform-upgrade
est utilisée pour effectuer la mise à niveau de la plate-forme.
Ajoutez le contenu du fichier
du-upgrade.yaml
au fichierkustomization.yaml
situé dans le dépôt ZTP Git pour les CRPolicyGenTemplate
et transférez les modifications dans le dépôt Git.ArgoCD extrait les modifications du référentiel Git et génère les politiques sur le cluster hub.
Vérifiez les politiques créées en exécutant la commande suivante :
oc get policies -A | grep platform-upgrade
$ oc get policies -A | grep platform-upgrade
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Appliquer les ressources de mise à jour requises avant de lancer la mise à jour de la plateforme avec le TALM.
Enregistrez le contenu du fichier
platform-upgrade-prep
ClusterUpgradeGroup
CR avec la stratégiedu-upgrade-platform-upgrade-prep
et les clusters gérés cibles dans le fichiercgu-platform-upgrade-prep.yml
, comme indiqué dans l'exemple suivant :Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appliquez la politique au cluster hub en exécutant la commande suivante :
oc apply -f cgu-platform-upgrade-prep.yml
$ oc apply -f cgu-platform-upgrade-prep.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus de mise à jour. Une fois la mise à jour terminée, assurez-vous que la politique est conforme en exécutant la commande suivante :
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créez le CR
ClusterGroupUpdate
pour la mise à jour de la plate-forme avec le champspec.enable
défini surfalse
.Enregistrez le contenu de la mise à jour de la plate-forme
ClusterGroupUpdate
CR avec la stratégiedu-upgrade-platform-upgrade
et les clusters cibles dans le fichiercgu-platform-upgrade.yml
, comme indiqué dans l'exemple suivant :Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appliquez le CR
ClusterGroupUpdate
au cluster du concentrateur en exécutant la commande suivante :oc apply -f cgu-platform-upgrade.yml
$ oc apply -f cgu-platform-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Facultatif : Prémettre en cache les images pour la mise à jour de la plateforme.
Activez la mise en cache préalable dans le CR
ClusterGroupUpdate
en exécutant la commande suivante :oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus de mise à jour et attendez la fin de la mise en cache. Vérifiez l'état de la mise en cache préalable en exécutant la commande suivante sur le cluster du concentrateur :
oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
$ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lancer la mise à jour de la plate-forme :
Activez la stratégie
cgu-platform-upgrade
et désactivez la mise en cache préalable en exécutant la commande suivante :oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus. Une fois le processus terminé, assurez-vous que la politique est conforme en exécutant la commande suivante :
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.10.1.3. Mise à jour de l'opérateur Copier lienLien copié sur presse-papiers!
Vous pouvez effectuer une mise à jour de l'opérateur avec le TALM.
Conditions préalables
- Installez le gestionnaire de cycle de vie Topology Aware (TALM).
- Mettre à jour ZTP avec la dernière version.
- Approvisionnez un ou plusieurs clusters gérés avec ZTP.
- Miroir de l'image d'index souhaitée, des images de la liasse et de toutes les images de l'opérateur référencées dans les images de la liasse.
-
Connectez-vous en tant qu'utilisateur disposant des privilèges
cluster-admin
. - Créer des stratégies RHACM dans le cluster hub.
Procédure
Mettre à jour le CR
PolicyGenTemplate
pour la mise à jour de l'opérateur.Mettez à jour le CR
du-upgrade
PolicyGenTemplate
avec le contenu supplémentaire suivant dans le fichierdu-upgrade.yaml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- L'URL de l'image d'index contient les images de l'opérateur souhaitées. Si les images d'index sont toujours poussées vers le même nom d'image et la même balise, cette modification n'est pas nécessaire.
- 2
- Le champ
registryPoll.interval
permet de définir la fréquence à laquelle le gestionnaire du cycle de vie de l'opérateur (OLM) interroge l'image d'index pour les nouvelles versions de l'opérateur. Cette modification n'est pas nécessaire si une nouvelle balise d'image d'index est toujours insérée pour les mises à jour des opérateurs des flux y et z. Le champregistryPoll.interval
peut être défini sur un intervalle plus court pour accélérer la mise à jour, mais les intervalles plus courts augmentent la charge de calcul. Pour y remédier, vous pouvez rétablir la valeur par défaut du champregistryPoll.interval
une fois la mise à jour terminée.
Cette mise à jour génère une politique,
du-upgrade-operator-catsrc-policy
, pour mettre à jour la source du catalogueredhat-operators
avec les nouvelles images d'index qui contiennent les images d'opérateurs souhaitées.NoteSi vous souhaitez utiliser la mise en cache préalable des images pour les opérateurs et qu'il existe des opérateurs provenant d'une source de catalogue autre que
redhat-operators
, vous devez effectuer les tâches suivantes :- Préparez une stratégie de source de catalogue distincte avec la nouvelle image d'index ou la mise à jour de l'intervalle d'interrogation du registre pour la source de catalogue différente.
- Préparer une politique d'abonnement distincte pour les opérateurs souhaités qui proviennent d'une source de catalogue différente.
Par exemple, l'opérateur SRIOV-FEC souhaité est disponible dans la source de catalogue
certified-operators
. Pour mettre à jour la source du catalogue et l'abonnement à l'opérateur, ajoutez le contenu suivant pour générer deux politiques,du-upgrade-fec-catsrc-policy
etdu-upgrade-subscriptions-fec-policy
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Supprime les canaux d'abonnement spécifiés dans le CR commun
PolicyGenTemplate
, s'ils existent. Les canaux d'abonnement par défaut de l'image ZTP sont utilisés pour la mise à jour.NoteLe canal par défaut pour les opérateurs appliqués par l'intermédiaire de ZTP 4.12 est
stable
, à l'exception deperformance-addon-operator
. À partir de OpenShift Container Platform 4.11, la fonctionnalitéperformance-addon-operator
a été déplacée versnode-tuning-operator
. Pour la version 4.10, le canal par défaut pour PAO estv4.10
. Vous pouvez également spécifier les canaux par défaut dans le CR communPolicyGenTemplate
.Pousser les mises à jour de
PolicyGenTemplate
CRs vers le dépôt ZTP Git.ArgoCD extrait les modifications du référentiel Git et génère les politiques sur le cluster hub.
Vérifiez les politiques créées en exécutant la commande suivante :
oc get policies -A | grep -E "catsrc-policy|subscription"
$ oc get policies -A | grep -E "catsrc-policy|subscription"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Appliquez les mises à jour nécessaires du catalogue avant de lancer la mise à jour de l'opérateur.
Enregistrez le contenu du CR
ClusterGroupUpgrade
nomméoperator-upgrade-prep
avec les stratégies source du catalogue et les clusters gérés cibles dans le fichiercgu-operator-upgrade-prep.yml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appliquez la politique au cluster hub en exécutant la commande suivante :
oc apply -f cgu-operator-upgrade-prep.yml
$ oc apply -f cgu-operator-upgrade-prep.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus de mise à jour. Une fois la mise à jour terminée, assurez-vous que la politique est conforme en exécutant la commande suivante :
oc get policies -A | grep -E "catsrc-policy"
$ oc get policies -A | grep -E "catsrc-policy"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créez le CR
ClusterGroupUpgrade
pour la mise à jour de l'opérateur avec le champspec.enable
défini surfalse
.Enregistrez le contenu de la mise à jour de l'opérateur
ClusterGroupUpgrade
CR avec la stratégiedu-upgrade-operator-catsrc-policy
et les stratégies d'abonnement créées à partir des clusters communsPolicyGenTemplate
et cibles dans le fichiercgu-operator-upgrade.yml
, comme indiqué dans l'exemple suivant :Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- La politique est nécessaire à la fonction de mise en cache préalable des images pour récupérer les images de l'opérateur à partir de la source du catalogue.
- 2
- La politique contient des abonnements d'opérateurs. Si vous avez suivi la structure et le contenu de la référence
PolicyGenTemplates
, tous les abonnements des opérateurs sont regroupés dans la politiquecommon-subscriptions-policy
.
NoteUn CR
ClusterGroupUpgrade
ne peut pré-cacher que les images des opérateurs souhaités définis dans la politique d'abonnement à partir d'une source de catalogue incluse dans le CRClusterGroupUpgrade
. Si les opérateurs souhaités proviennent de différentes sources de catalogue, comme dans l'exemple de l'opérateur SRIOV-FEC, un autre CRClusterGroupUpgrade
doit être créé avec les politiquesdu-upgrade-fec-catsrc-policy
etdu-upgrade-subscriptions-fec-policy
pour la mise en cache et la mise à jour des images de l'opérateur SRIOV-FEC.Appliquez le CR
ClusterGroupUpgrade
au cluster du concentrateur en exécutant la commande suivante :oc apply -f cgu-operator-upgrade.yml
$ oc apply -f cgu-operator-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Facultatif : Prémettre en cache les images pour la mise à jour de l'opérateur.
Avant de commencer la mise en cache des images, vérifiez que la politique d'abonnement est bien
NonCompliant
à ce stade en exécutant la commande suivante :oc get policy common-subscriptions-policy -n <policy_namespace>
$ oc get policy common-subscriptions-policy -n <policy_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Activez la mise en cache préalable dans le CR
ClusterGroupUpgrade
en exécutant la commande suivante :oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus et attendez la fin de la mise en cache. Vérifiez l'état de la mise en cache préalable en exécutant la commande suivante sur le cluster géré :
oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
$ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifiez que la mise en cache est terminée avant de lancer la mise à jour en exécutant la commande suivante :
oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq
$ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lancer la mise à jour de l'opérateur.
Activez le
cgu-operator-upgrade
ClusterGroupUpgrade
CR et désactivez la mise en cache préalable pour lancer la mise à jour de l'opérateur en exécutant la commande suivante :oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus. Une fois le processus terminé, assurez-vous que la politique est conforme en exécutant la commande suivante :
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.10.1.4. Réalisation conjointe d'une mise à jour de la plate-forme et d'une mise à jour de l'opérateur Copier lienLien copié sur presse-papiers!
Vous pouvez effectuer une mise à jour de la plate-forme et de l'opérateur en même temps.
Conditions préalables
- Installez le gestionnaire de cycle de vie Topology Aware (TALM).
- Mettre à jour ZTP avec la dernière version.
- Approvisionnez un ou plusieurs clusters gérés avec ZTP.
-
Connectez-vous en tant qu'utilisateur disposant des privilèges
cluster-admin
. - Créer des stratégies RHACM dans le cluster hub.
Procédure
-
Créez le CR
PolicyGenTemplate
pour les mises à jour en suivant les étapes décrites dans les sections "Effectuer une mise à jour de la plate-forme" et "Effectuer une mise à jour de l'opérateur". Appliquer les travaux préparatoires pour la plateforme et la mise à jour de l'opérateur.
Enregistrez le contenu du fichier
ClusterGroupUpgrade
CR avec les politiques de préparation des mises à jour de la plate-forme, les mises à jour de la source du catalogue et les clusters cibles dans le fichiercgu-platform-operator-upgrade-prep.yml
, par exemple :Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appliquez le fichier
cgu-platform-operator-upgrade-prep.yml
au cluster hub en exécutant la commande suivante :oc apply -f cgu-platform-operator-upgrade-prep.yml
$ oc apply -f cgu-platform-operator-upgrade-prep.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus. Une fois le processus terminé, assurez-vous que la politique est conforme en exécutant la commande suivante :
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Créez le CR
ClusterGroupUpdate
pour la plate-forme et la mise à jour de l'opérateur avec le champspec.enable
réglé surfalse
.Enregistrez le contenu de la plateforme et de la mise à jour de l'opérateur
ClusterGroupUpdate
CR avec les politiques et les clusters cibles dans le fichiercgu-platform-operator-upgrade.yml
, comme indiqué dans l'exemple suivant :Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Il s'agit de la politique de mise à jour de la plateforme.
- 2
- Il s'agit de la stratégie contenant les informations de source du catalogue pour les opérateurs à mettre à jour. Elle est nécessaire pour que la fonction de mise en cache préalable détermine les images d'opérateurs à télécharger sur le cluster géré.
- 3
- Il s'agit de la politique de mise à jour des opérateurs.
Appliquez le fichier
cgu-platform-operator-upgrade.yml
au cluster hub en exécutant la commande suivante :oc apply -f cgu-platform-operator-upgrade.yml
$ oc apply -f cgu-platform-operator-upgrade.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Facultatif : Pré-cachez les images pour la plateforme et la mise à jour de l'opérateur.
Activez la mise en cache préalable dans le CR
ClusterGroupUpgrade
en exécutant la commande suivante :oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus de mise à jour et attendez la fin de la mise en cache. Vérifiez l'état de la mise en cache préalable en exécutant la commande suivante sur le cluster géré :
oc get jobs,pods -n openshift-talm-pre-cache
$ oc get jobs,pods -n openshift-talm-pre-cache
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifiez que la mise en cache est terminée avant de lancer la mise à jour en exécutant la commande suivante :
oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
$ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Démarrer la plateforme et la mise à jour de l'opérateur.
Activez le
cgu-du-upgrade
ClusterGroupUpgrade
CR pour démarrer la plateforme et la mise à jour de l'opérateur en exécutant la commande suivante :oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Surveillez le processus. Une fois le processus terminé, assurez-vous que la politique est conforme en exécutant la commande suivante :
oc get policies --all-namespaces
$ oc get policies --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteLes CR pour les mises à jour de la plate-forme et de l'opérateur peuvent être créés dès le début en configurant le paramètre
spec.enable: true
. Dans ce cas, la mise à jour démarre immédiatement après la fin de la mise en cache préalable et il n'est pas nécessaire d'activer manuellement le CR.La mise en cache préalable et la mise à jour créent des ressources supplémentaires, telles que des stratégies, des liaisons de placement, des règles de placement, des actions de cluster géré et des vues de cluster géré, afin de faciliter l'exécution des procédures. La définition du champ
afterCompletion.deleteObjects
surtrue
supprime toutes ces ressources une fois les mises à jour terminées.
21.10.1.5. Suppression des abonnements Performance Addon Operator des clusters déployés Copier lienLien copié sur presse-papiers!
Dans les versions antérieures d'OpenShift Container Platform, l'opérateur Performance Addon fournissait un réglage automatique des performances à faible latence pour les applications. Dans OpenShift Container Platform 4.11 ou ultérieure, ces fonctions font partie de l'opérateur Node Tuning.
N'installez pas l'opérateur Performance Addon sur des clusters exécutant OpenShift Container Platform 4.11 ou une version ultérieure. Si vous mettez à niveau vers OpenShift Container Platform 4.11 ou une version ultérieure, l'opérateur Node Tuning supprime automatiquement l'opérateur Performance Addon.
Vous devez supprimer toutes les stratégies qui créent des abonnements à Performance Addon Operator afin d'empêcher la réinstallation de l'opérateur.
Le profil DU de référence inclut l'opérateur Performance Addon dans le CR PolicyGenTemplate
common-ranGen.yaml
. Pour supprimer l'abonnement des clusters gérés déployés, vous devez mettre à jour common-ranGen.yaml
.
Si vous installez Performance Addon Operator 4.10.3-5 ou une version ultérieure sur OpenShift Container Platform 4.11 ou une version ultérieure, Performance Addon Operator détecte la version du cluster et se met automatiquement en hibernation pour éviter d'interférer avec les fonctions de Node Tuning Operator. Cependant, pour garantir des performances optimales, supprimez le Performance Addon Operator de vos clusters OpenShift Container Platform 4.11.
Conditions préalables
- Créez un dépôt Git où vous gérez les données de configuration de votre site personnalisé. Le dépôt doit être accessible depuis le cluster hub et être défini comme dépôt source pour ArgoCD.
- Mise à jour vers OpenShift Container Platform 4.11 ou une version ultérieure.
-
Connectez-vous en tant qu'utilisateur disposant des privilèges
cluster-admin
.
Procédure
Remplacez
complianceType
parmustnothave
pour l'espace de noms Performance Addon Operator, le groupe Operator et l'abonnement dans le fichiercommon-ranGen.yaml
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Fusionnez les modifications avec votre référentiel de site personnalisé et attendez que l'application ArgoCD synchronise les modifications avec le cluster du concentrateur. Le statut de la politique
common-subscriptions-policy
devientNon-Compliant
. - Appliquez la modification à vos clusters cibles à l'aide du gestionnaire de cycle de vie Topology Aware. Pour plus d'informations sur le déploiement des modifications de configuration, voir la section "Ressources supplémentaires".
Surveillez le processus. Lorsque le statut de la politique
common-subscriptions-policy
pour un cluster cible estCompliant
, l'opérateur Performance Addon a été supprimé du cluster. Obtenez le statut decommon-subscriptions-policy
en exécutant la commande suivante :oc get policy -n ztp-common common-subscriptions-policy
$ oc get policy -n ztp-common common-subscriptions-policy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Supprimer l'espace de noms de l'opérateur Performance Addon, le groupe d'opérateurs et les CR d'abonnement de
.spec.sourceFiles
dans le fichiercommon-ranGen.yaml
. - Fusionnez les modifications avec votre référentiel de site personnalisé et attendez que l'application ArgoCD synchronise les modifications avec le cluster du concentrateur. La politique reste conforme.
21.10.2. À propos de la création automatique de ClusterGroupUpgrade CR pour ZTP Copier lienLien copié sur presse-papiers!
TALM dispose d'un contrôleur appelé ManagedClusterForCGU
qui surveille l'état Ready
des CR ManagedCluster
sur le cluster hub et crée les CR ClusterGroupUpgrade
pour le ZTP (zero touch provisioning).
Pour tout cluster géré dans l'état Ready
sans étiquette "ztp-done" appliquée, le contrôleur ManagedClusterForCGU
crée automatiquement un CR ClusterGroupUpgrade
dans l'espace de noms ztp-install
avec ses politiques RHACM associées qui sont créées pendant le processus ZTP. Le TALM remédie ensuite à l'ensemble des politiques de configuration répertoriées dans le CR ClusterGroupUpgrade
auto-créé pour pousser les CR de configuration vers le cluster géré.
Si le cluster géré n'a pas de politiques liées lorsque le cluster devient Ready
, aucun CR ClusterGroupUpgrade
n'est créé.
Exemple d'un CR ClusterGroupUpgrade
auto-créé pour ZTP