21.9. Configuration avancée des clusters gérés avec les ressources PolicyGenTemplate

Procédure

1. Examinez le CR source de référence à la recherche de contenu existant. Vous pouvez examiner les CR source répertoriés dans la référence PolicyGenTemplate CR en les extrayant du conteneur ZTP (Zero Touch Provisioning).

   1. Créez un dossier /out:

      $ mkdir -p ./out

   2. Extraire les CR source :

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 extract /home/ztp --tar | tar x -C ./out

2. Examinez le document de référence PerformanceProfile CR à l'adresse ./out/source-crs/PerformanceProfile.yaml:

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: $name
     annotations:
       ran.openshift.io/ztp-deploy-wave: "10"
   spec:
     additionalKernelArgs:
     - "idle=poll"
     - "rcupdate.rcu_normal_after_boot=0"
     cpu:
       isolated: $isolated
       reserved: $reserved
     hugepages:
       defaultHugepagesSize: $defaultHugepagesSize
       pages:
         - size: $size
           count: $count
           node: $node
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/$mcp: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/$mcp: ''
     numa:
       topologyPolicy: "restricted"
     realTimeKernel:
       enabled: true

   Note

   Tous les champs du CR source qui contiennent $…​ sont supprimés du CR généré s'ils ne sont pas fournis dans le CR PolicyGenTemplate.

3. Mettez à jour l'entrée PolicyGenTemplate pour PerformanceProfile dans le fichier de référence group-du-sno-ranGen.yaml. L'exemple suivant de strophe PolicyGenTemplate CR fournit les spécifications appropriées de l'unité centrale, définit la configuration de hugepages et ajoute un nouveau champ qui définit globallyDisableIrqLoadBalancing comme faux.

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       name: openshift-node-performance-profile
     spec:
       cpu:
         # These must be tailored for the specific hardware platform
         isolated: "2-19,22-39"
         reserved: "0-1,20-21"
       hugepages:
         defaultHugepagesSize: 1G
         pages:
           - size: 1G
             count: 10
       globallyDisableIrqLoadBalancing: false

4. Commencer le changement PolicyGenTemplate dans Git, puis pousser vers le dépôt Git surveillé par l'application GitOps ZTP argo CD.

Procédure

1. Créez un répertoire contenant un fichier Containerfile et les fichiers YAML du CR source que vous souhaitez inclure dans le conteneur ztp-site-generate mis à jour, par exemple :

   ztp-update/
   ├── example-cr1.yaml
   ├── example-cr2.yaml
   └── ztp-update.in

2. Ajoutez le contenu suivant au fichier de conteneurs ztp-update.in:

   FROM registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12
   
   ADD example-cr2.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/
   ADD example-cr1.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/

3. Ouvrez un terminal dans le dossier ztp-update/ et reconstruisez le conteneur :

   $ podman build -t ztp-site-generate-rhel8-custom:v4.12-custom-1

4. Pousser l'image du conteneur construit vers votre registre déconnecté, par exemple :

   $ podman push localhost/ztp-site-generate-rhel8-custom:v4.12-custom-1 registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.12-custom-1

5. Patch de l'instance Argo CD sur le cluster hub pour pointer vers l'image de conteneur nouvellement construite :

   $ oc patch -n openshift-gitops argocd openshift-gitops --type=json -p '[{"op": "replace", "path":"/spec/repo/initContainers/0/image", "value": "registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.12-custom-1"} ]'

   Lorsque l'instance Argo CD est corrigée, le pod openshift-gitops-repo-server redémarre automatiquement.

Vérification

1. Vérifiez que le nouveau pod openshift-gitops-repo-server a terminé son initialisation et que le pod repo précédent est terminé :

   $ oc get pods -n openshift-gitops | grep openshift-gitops-repo-server

   Exemple de sortie

   openshift-gitops-server-7df86f9774-db682          1/1     Running   	     1          28s

   Vous devez attendre que le nouveau pod openshift-gitops-repo-server ait terminé son initialisation et que le pod précédent soit terminé pour que le contenu de l'image de conteneur nouvellement ajoutée soit disponible.

Procédure

1. Pour configurer l'intervalle d'évaluation de toutes les politiques dans une CR PolicyGenTemplate, ajoutez evaluationInterval au champ spec, puis définissez les valeurs compliant et noncompliant appropriées. Par exemple :

   spec:
     evaluationInterval:
       compliant: 30m
       noncompliant: 20s

2. Pour configurer l'intervalle d'évaluation de l'objet spec.sourceFiles dans un CR PolicyGenTemplate, ajoutez evaluationInterval au champ sourceFiles, par exemple :

   spec:
     sourceFiles:
      - fileName: SriovSubscription.yaml
        policyName: "sriov-sub-policy"
        evaluationInterval:
          compliant: never
          noncompliant: 10s

3. Commencez les fichiers PolicyGenTemplate CRs dans le dépôt Git et apportez vos modifications.

1. Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin sur le cluster géré.

2. Obtenez les pods qui sont en cours d'exécution dans l'espace de noms open-cluster-management-agent-addon. Exécutez la commande suivante :

   $ oc get pods -n open-cluster-management-agent-addon

   Exemple de sortie

   NAME                                         READY   STATUS    RESTARTS        AGE
   config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d

3. Vérifiez que les politiques appliquées sont évaluées à l'intervalle prévu dans les journaux du pod config-policy-controller:

   $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb

   Exemple de sortie

   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-config-policy-config"}
   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-common-compute-1-catalog-policy-config"}

Procédure

1. Créez une ressource personnalisée (CR) autonome PolicyGenTemplate qui contient le fichier source validatorCRs/informDuValidator.yaml. Vous n'avez besoin que d'une CR PolicyGenTemplate autonome pour chaque type de cluster. Par exemple, cette CR applique une politique d'information du validateur pour les clusters OpenShift à nœud unique :

   Exemple de politique d'information de validateur de cluster à nœud unique CR (group-du-sno-validator-ranGen.yaml)

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-du-sno-validator" 1
     namespace: "ztp-group" 2
   spec:
     bindingRules:
       group-du-sno: "" 3
     bindingExcludedRules:
       ztp-done: "" 4
     mcp: "master" 5
     sourceFiles:
       - fileName: validatorCRs/informDuValidator.yaml
         remediationAction: inform 6
         policyName: "du-policy" 7

   1

   Le nom de l'objet PolicyGenTemplates. Ce nom est également utilisé dans les noms des objets placementBinding, placementRule, et policy qui sont créés dans l'objet namespace.

   2

   Cette valeur doit correspondre à celle de namespace utilisée dans le groupe PolicyGenTemplates.

   3

   L'étiquette group-du-* définie dans bindingRules doit exister dans les fichiers SiteConfig.

   4

   Le label défini dans bindingExcludedRules doit être "ztp-done:`". Le label ztp-done est utilisé en coordination avec le Topology Aware Lifecycle Manager.

   5

   mcp définit l'objet MachineConfigPool utilisé dans le fichier source validatorCRs/informDuValidator.yaml. Il doit s'agir de master pour les déploiements de clusters à un ou trois nœuds et de worker pour les déploiements de clusters standard.

   6

   Facultatif. La valeur par défaut est inform.

   7

   Cette valeur fait partie du nom de la stratégie RHACM générée. La stratégie de validation générée pour l'exemple d'un seul nœud est group-du-sno-validator-du-policy.

2. Commencez le fichier PolicyGenTemplate CR dans votre dépôt Git et transférez les modifications.

Procédure

1. Ajoutez le YAML suivant à .spec.sourceFiles dans le fichier common-ranGen.yaml pour configurer l'opérateur AMQP :

   #AMQ interconnect operator for fast events
   - fileName: AmqSubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscription.yaml
     policyName: "subscriptions-policy"

2. Appliquez les modifications suivantes à PolicyGenTemplate aux fichiers group-du-3node-ranGen.yaml, group-du-sno-ranGen.yaml ou group-du-standard-ranGen.yaml en fonction de vos besoins :

   1. Dans .sourceFiles, ajoutez le fichier PtpOperatorConfig CR qui configure l'hôte de transport AMQ à config-policy:

      - fileName: PtpOperatorConfigForEvent.yaml
        policyName: "config-policy"

   2. Configurez les pages linuxptp et phc2sys pour le type d'horloge PTP et l'interface. Par exemple, ajoutez la strophe suivante à .sourceFiles:

      - fileName: PtpConfigSlave.yaml 1
        policyName: "config-policy"
        metadata:
          name: "du-ptp-slave"
        spec:
          profile:
          - name: "slave"
            interface: "ens5f1" 2
            ptp4lOpts: "-2 -s --summary_interval -4" 3
            phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 4
          ptpClockThreshold: 5
            holdOverTimeout: 30 #secs
            maxOffsetThreshold: 100  #nano secs
            minOffsetThreshold: -100 #nano secs

      1

      Il peut s'agir de PtpConfigMaster.yaml, PtpConfigSlave.yaml, ou PtpConfigSlaveCvl.yaml en fonction de vos besoins. PtpConfigSlaveCvl.yaml configure les services linuxptp pour un NIC Intel E810 Columbiaville. Pour les configurations basées sur group-du-sno-ranGen.yaml ou group-du-3node-ranGen.yaml, utilisez PtpConfigSlave.yaml.

      2

      Nom de l'interface spécifique au dispositif.

      3

      Vous devez ajouter la valeur --summary_interval -4 à ptp4lOpts dans .spec.sourceFiles.spec.profile pour activer les événements rapides PTP.

      4

      Valeurs requises phc2sysOpts. -m imprime des messages à stdout. linuxptp-daemon DaemonSet analyse les journaux et génère des métriques Prometheus.

      5

      Facultatif. Si la strophe ptpClockThreshold n'est pas présente, des valeurs par défaut sont utilisées pour les champs ptpClockThreshold. La strophe indique les valeurs par défaut de ptpClockThreshold. Les valeurs de ptpClockThreshold configurent le délai de déclenchement des événements PTP après la déconnexion de l'horloge maître PTP. holdOverTimeout est la valeur de temps en secondes avant que l'état de l'événement de l'horloge PTP ne passe à FREERUN lorsque l'horloge maître PTP est déconnectée. Les paramètres maxOffsetThreshold et minOffsetThreshold configurent des valeurs de décalage en nanosecondes qui se comparent aux valeurs de CLOCK_REALTIME (phc2sys) ou au décalage du maître (ptp4l). Lorsque la valeur de décalage ptp4l ou phc2sys est en dehors de cette plage, l'état de l'horloge PTP est réglé sur FREERUN. Lorsque la valeur de décalage est comprise dans cette plage, l'état de l'horloge PTP est réglé sur LOCKED.

3. Appliquez les modifications suivantes PolicyGenTemplate aux fichiers YAML de votre site, par exemple example-sno-site.yaml:

   1. Dans .sourceFiles, ajoutez le fichier Interconnect CR qui configure le routeur AMQ à config-policy:

      - fileName: AmqInstance.yaml
        policyName: "config-policy"

4. Fusionnez tous les autres changements et fichiers nécessaires avec votre référentiel de site personnalisé.
5. Transférez les modifications dans le référentiel de configuration de votre site pour déployer les événements rapides PTP sur de nouveaux sites à l'aide de GitOps ZTP.

Procédure

1. Pour configurer l'opérateur d'interconnexion AMQ et l'opérateur de relais d'événements Bare Metal, ajoutez le fichier YAML suivant à spec.sourceFiles dans le fichier common-ranGen.yaml:

   # AMQ interconnect operator for fast events
   - fileName: AmqSubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: AmqSubscription.yaml
     policyName: "subscriptions-policy"
   # Bare Metal Event Rely operator
   - fileName: BareMetalEventRelaySubscriptionNS.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
     policyName: "subscriptions-policy"
   - fileName: BareMetalEventRelaySubscription.yaml
     policyName: "subscriptions-policy"

2. Ajoutez le CR Interconnect à .spec.sourceFiles dans le fichier de configuration du site, par exemple le fichier example-sno-site.yaml:

   - fileName: AmqInstance.yaml
     policyName: "config-policy"

3. Ajoutez le CR HardwareEvent à spec.sourceFiles dans votre fichier de configuration de groupe spécifique, par exemple dans le fichier group-du-sno-ranGen.yaml:

   - fileName: HardwareEvent.yaml
     policyName: "config-policy"
     spec:
       nodeSelector: {}
       transportHost: "amqp://<amq_interconnect_name>.<amq_interconnect_namespace>.svc.cluster.local" 1
       logLevel: "info"

   1

   L'URL transportHost est composée des CR AMQ Interconnect existants name et namespace. Par exemple, dans transportHost: "amqp://amq-router.amq-router.svc.cluster.local", les AMQ Interconnect name et namespace sont tous deux définis sur amq-router.

   Note

   Chaque contrôleur de gestion de carte de base (BMC) ne nécessite qu'une seule ressource HardwareEvent.

4. Validez le changement PolicyGenTemplate dans Git, puis transférez les changements dans le référentiel de configuration de votre site pour déployer la surveillance des événements sur de nouveaux sites à l'aide du protocole ZTP de GitOps.

5. Créez le Secret Redfish en exécutant la commande suivante :

   $ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \
   --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \
   --from-literal=hostaddr="<bmc_host_ip_addr>"