21.4. Configuration de clusters gérés avec des politiques et des ressources PolicyGenTemplate

Procédure

1. Créer un CR PolicyGenTemplate pour les CR de configuration spécifiques au site.

   1. Choisissez l'exemple approprié pour votre CR dans le dossier out/argocd/example/policygentemplates, par exemple, example-sno-site.yaml ou example-multinode-site.yaml.

   2. Modifiez le champ bindingRules dans le fichier d'exemple pour qu'il corresponde à l'étiquette spécifique au site incluse dans le CR SiteConfig. Dans l'exemple de fichier SiteConfig, l'étiquette spécifique au site est sites: example-sno.

      Note

      Veillez à ce que les étiquettes définies dans votre champ PolicyGenTemplate bindingRules correspondent aux étiquettes définies dans les clusters gérés connexes SiteConfig CR.

   3. Modifiez le contenu du fichier d'exemple pour qu'il corresponde à la configuration souhaitée.

2. Facultatif : Créez une CR PolicyGenTemplate pour toutes les CR de configuration commune qui s'appliquent à l'ensemble de la flotte de clusters.

   1. Sélectionnez l'exemple approprié pour votre CR dans le dossier out/argocd/example/policygentemplates, par exemple common-ranGen.yaml.
   2. Modifiez le contenu du fichier d'exemple pour qu'il corresponde à la configuration souhaitée.

3. Facultatif : Créez un CR PolicyGenTemplate pour tous les CR de configuration de groupe qui s'appliquent à certains groupes de clusters dans la flotte.

   Assurez-vous que le contenu des fichiers spec superposés correspond à l'état final souhaité. À titre de référence, le répertoire out/source-crs contient la liste complète des sources-crs disponibles pour être incluses et superposées par vos modèles PolicyGenTemplate.

   Note

   En fonction des exigences spécifiques de vos clusters, il se peut que vous ayez besoin de plus d'une stratégie de groupe par type de cluster, surtout si l'on considère que les stratégies de groupe de l'exemple ont chacune un seul fichier PerformancePolicy.yaml qui ne peut être partagé sur un ensemble de clusters que si ces clusters sont constitués de configurations matérielles identiques.

   1. Sélectionnez l'exemple approprié pour votre CR dans le dossier out/argocd/example/policygentemplates, par exemple group-du-sno-ranGen.yaml.
   2. Modifiez le contenu du fichier d'exemple pour qu'il corresponde à la configuration souhaitée.
4. Facultatif. Créez un validator inform policy PolicyGenTemplate CR pour signaler que l'installation et la configuration ZTP de la grappe déployée sont terminées. Pour plus d'informations, voir "Creating a validator inform policy".

5. Définir tous les espaces de noms de la politique dans un fichier YAML similaire à l'exemple de fichier out/argocd/example/policygentemplates/ns.yaml.

   Important

   Ne pas inclure le CR Namespace dans le même fichier que le CR PolicyGenTemplate.

6. Ajoutez les CR PolicyGenTemplate et Namespace au fichier kustomization.yaml dans la section des générateurs, comme dans l'exemple présenté dans out/argocd/example/policygentemplates/kustomization.yaml.

7. Commencez les CR PolicyGenTemplate, CR Namespace et le fichier kustomization.yaml associé dans votre dépôt Git et repoussez les changements.

   Le pipeline ArgoCD détecte les modifications et commence le déploiement du cluster géré. Vous pouvez pousser les modifications vers le CR SiteConfig et le CR PolicyGenTemplate simultanément.

Procédure

1. Le Topology Aware Lifecycle Manager (TALM) applique les politiques de configuration liées à la grappe.

   Une fois l'installation du cluster terminée et le cluster devenu Ready, un CR ClusterGroupUpgrade correspondant à ce cluster, avec une liste de politiques ordonnées définies par ran.openshift.io/ztp-deploy-wave annotations, est automatiquement créé par le TALM. Les politiques de la grappe sont appliquées dans l'ordre indiqué dans ClusterGroupUpgrade CR.

   Vous pouvez contrôler l'avancement de la réconciliation des politiques de configuration à l'aide des commandes suivantes :

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

   Exemple de sortie

   {
     "lastTransitionTime": "2022-11-09T07:28:09Z",
     "message": "Remediating non-compliant policies",
     "reason": "InProgress",
     "status": "True",
     "type": "Progressing"
   }

2. Vous pouvez contrôler l'état détaillé de la conformité de la politique de cluster en utilisant le tableau de bord RHACM ou la ligne de commande.

   1. Pour vérifier la conformité de la politique à l'aide de oc, exécutez la commande suivante :

      $ oc get policies -n $CLUSTER

      Exemple de sortie

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

   2. Pour vérifier l'état des politiques à partir de la console Web RHACM, effectuez les actions suivantes :

      1. Cliquez sur Governance Find policies.
      2. Cliquez sur une politique de cluster pour vérifier son statut.

Procédure

1. Pour afficher des informations détaillées sur les politiques, exécutez la commande suivante :

   $ oc describe -n openshift-gitops application policies

2. Vérifiez que Status: Conditions: est affiché dans les journaux d'erreurs. Par exemple, la définition d'une adresse sourceFile→fileName: invalide génère l'erreur suivante :

   Status:
     Conditions:
       Last Transition Time:  2021-11-26T17:21:39Z
       Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
       Type:  ComparisonError

3. Vérifiez Status: Sync:. S'il y a des erreurs d'enregistrement à Status: Conditions:, le site Status: Sync: affiche Unknown ou Error:

   Status:
     Sync:
       Compared To:
         Destination:
           Namespace:  policies-sub
           Server:     https://kubernetes.default.svc
         Source:
           Path:             policies
           Repo URL:         https://git.com/ran-sites/policies/.git
           Target Revision:  master
       Status:               Error

4. Lorsque Red Hat Advanced Cluster Management (RHACM) reconnaît que des stratégies s'appliquent à un objet ManagedCluster, les objets CR de stratégie sont appliqués à l'espace de noms du cluster. Vérifiez si les stratégies ont été copiées dans l'espace de noms du cluster :

   $ oc get policy -n $CLUSTER

   Exemple de sortie :

   NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
   ztp-common.common-config-policy              inform               Compliant          13d
   ztp-common.common-subscriptions-policy       inform               Compliant          13d
   ztp-group.group-du-sno-config-policy         inform               Compliant          13d
   Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
   ztp-site.example-sno-config-policy           inform               Compliant          13d

   RHACM copie toutes les politiques applicables dans l'espace de noms du cluster. Les noms des stratégies copiées ont le format suivant : <policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName>.

5. Vérifiez la règle de placement pour toutes les politiques qui n'ont pas été copiées dans l'espace de noms du cluster. Les matchSelector dans le PlacementRule pour ces politiques doivent correspondre aux étiquettes de l'objet ManagedCluster:

   $ oc get placementrule -n $NS

6. Notez le nom PlacementRule approprié pour la politique, le commun, le groupe ou le site manquant, à l'aide de la commande suivante :

   oc get placementrule -n $NS <placementRuleName> -o yaml

   • Les décisions d'état doivent inclure le nom de votre cluster.
   • La paire clé-valeur de matchSelector dans la spécification doit correspondre aux étiquettes de votre cluster géré.

7. Vérifiez les étiquettes de l'objet ManagedCluster à l'aide de la commande suivante :

   $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq

8. Vérifiez quelles politiques sont conformes à l'aide de la commande suivante :

   $ oc get policy -n $CLUSTER

   Si les stratégies Namespace, OperatorGroup et Subscription sont conformes mais que les stratégies de configuration de l'opérateur ne le sont pas, il est probable que les opérateurs ne se sont pas installés sur le cluster géré. Dans ce cas, les politiques de configuration de l'opérateur ne s'appliquent pas car le CRD n'est pas encore appliqué au rayon.

Procédure

1. Un CR ClusterGroupUpgrade est généré dans l'espace de noms ztp-install par le Topology Aware Lifecycle Manager une fois que le cluster géré devient Ready:

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER

2. Si des problèmes inattendus surviennent et que les politiques ne sont pas réclamées dans le délai configuré (4 heures par défaut), l'état de la CR ClusterGroupUpgrade est indiqué par UpgradeTimedOut:

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'

3. Un CR ClusterGroupUpgrade dans l'état UpgradeTimedOut redémarre automatiquement son rapprochement des politiques toutes les heures. Si vous avez modifié vos politiques, vous pouvez lancer une nouvelle tentative immédiatement en supprimant le CR ClusterGroupUpgrade existant. Cela déclenche la création automatique d'un nouveau CR ClusterGroupUpgrade qui commence immédiatement à réconcilier les politiques :

   $ oc delete clustergroupupgrades -n ztp-install $CLUSTER