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


Vous pouvez utiliser les CR PolicyGenTemplate pour déployer des fonctionnalités personnalisées dans vos clusters gérés.

Si vous souhaitez modifier la configuration du cluster en dehors de la configuration de base du pipeline ZTP de GitOps, trois options s'offrent à vous :

Appliquer la configuration supplémentaire une fois que le pipeline ZTP est terminé
Lorsque le déploiement du pipeline ZTP de GitOps est terminé, le cluster déployé est prêt pour les charges de travail des applications. À ce stade, vous pouvez installer des opérateurs supplémentaires et appliquer des configurations spécifiques à vos besoins. Assurez-vous que les configurations supplémentaires n'affectent pas négativement les performances de la plateforme ou le budget CPU alloué.
Ajouter du contenu à la bibliothèque ZTP
Les ressources personnalisées (CR) de base que vous déployez avec le pipeline ZTP de GitOps peuvent être complétées par du contenu personnalisé selon les besoins.
Créer des manifestes supplémentaires pour l'installation du cluster
Les manifestes supplémentaires sont appliqués pendant l'installation et rendent le processus d'installation plus efficace.
Important

Fournir des CR source supplémentaires ou modifier des CR source existants peut avoir un impact significatif sur la performance ou le profil CPU d'OpenShift Container Platform.

PolicyGenTemplate les ressources personnalisées (CR) vous permettent de superposer des détails de configuration supplémentaires aux CR de base fournis avec le plugin GitOps dans le conteneur ztp-site-generate. Vous pouvez considérer les CR PolicyGenTemplate comme une fusion logique ou un correctif de la CR de base. Utilisez les CR PolicyGenTemplate pour mettre à jour un seul champ du CR de base, ou pour superposer l'ensemble du contenu du CR de base. Vous pouvez mettre à jour des valeurs et insérer des champs qui ne figurent pas dans le CR de base.

L'exemple de procédure suivant décrit comment mettre à jour les champs du CR PerformanceProfile généré pour la configuration de référence sur la base du CR PolicyGenTemplate dans le fichier group-du-sno-ranGen.yaml. Utilisez cette procédure comme base pour modifier d'autres parties de PolicyGenTemplate en fonction de vos besoins.

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 Argo CD.

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
      Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
  4. Commencer le changement PolicyGenTemplate dans Git, puis pousser vers le dépôt Git surveillé par l'application GitOps ZTP argo CD.

Exemple de sortie

L'application ZTP génère une politique RHACM qui contient la CR PerformanceProfile générée. Le contenu de ce CR est obtenu en fusionnant les contenus metadata et spec de l'entrée PerformanceProfile dans le PolicyGenTemplate sur le CR source. Le CR résultant a le contenu suivant :

---
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
    name: openshift-node-performance-profile
spec:
    additionalKernelArgs:
        - idle=poll
        - rcupdate.rcu_normal_after_boot=0
    cpu:
        isolated: 2-19,22-39
        reserved: 0-1,20-21
    globallyDisableIrqLoadBalancing: false
    hugepages:
        defaultHugepagesSize: 1G
        pages:
            - count: 10
              size: 1G
    machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/master: ""
    net:
        userLevelNetworking: true
    nodeSelector:
        node-role.kubernetes.io/master: ""
    numa:
        topologyPolicy: restricted
    realTimeKernel:
        enabled: true
Copy to Clipboard Toggle word wrap
Note

Dans le dossier /source-crs que vous extrayez du conteneur ztp-site-generate, la syntaxe $ n'est pas utilisée pour la substitution de modèle comme le suggère la syntaxe. Au contraire, si l'outil policyGen voit le préfixe $ pour une chaîne et que vous ne spécifiez pas de valeur pour ce champ dans le CR PolicyGenTemplate correspondant, le champ est entièrement omis du CR de sortie.

Une exception à cette règle est la variable $mcp dans les fichiers YAML /source-crs, qui est remplacée par la valeur spécifiée pour mcp dans le CR PolicyGenTemplate. Par exemple, dans example/policygentemplates/group-du-standard-ranGen.yaml, la valeur de mcp est worker:

spec:
  bindingRules:
    group-du-standard: ""
  mcp: "worker"
Copy to Clipboard Toggle word wrap

L'outil policyGen remplace les instances de $mcp par worker dans les CR de sortie.

21.9.3. Ajouter un nouveau contenu au pipeline ZTP de GitOps

Les CR source du conteneur de générateur de site ZTP de GitOps fournissent un ensemble de fonctionnalités critiques et de paramètres de réglage des nœuds pour les applications d'unités distribuées (UD) du RAN. Ils sont appliqués aux clusters que vous déployez avec ZTP. Pour ajouter ou modifier des CR source existants dans le conteneur ztp-site-generate, reconstruisez le conteneur ztp-site-generate et mettez-le à la disposition du cluster concentrateur, généralement à partir du registre déconnecté associé au cluster concentrateur. Tout CR valide de OpenShift Container Platform peut être ajouté.

Suivez la procédure suivante pour ajouter un nouveau contenu au pipeline ZTP.

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
    Copy to Clipboard Toggle word wrap
  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/
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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"} ]'
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    openshift-gitops-server-7df86f9774-db682          1/1     Running   	     1          28s
    Copy to Clipboard Toggle word wrap

    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.

Utilisez Red Hat Advanced Cluster Management (RHACM) installé sur un cluster hub pour surveiller et signaler si vos clusters gérés sont conformes aux stratégies appliquées. RHACM utilise des modèles de politiques pour appliquer des contrôleurs de politiques et des politiques prédéfinis. Les contrôleurs de politiques sont des instances de définition de ressources personnalisées (CRD) Kubernetes.

Vous pouvez remplacer les intervalles d'évaluation des politiques par défaut par des ressources personnalisées (CR) sur le site PolicyGenTemplate. Vous configurez les paramètres de durée qui définissent combien de temps une CR ConfigurationPolicy peut rester dans un état de conformité ou de non-conformité à la politique avant que RHACM ne réévalue les politiques de cluster appliquées.

Le générateur de politiques ZTP (zero touch provisioning) génère des politiques CR ConfigurationPolicy avec des intervalles d'évaluation prédéfinis. La valeur par défaut de l'état noncompliant est de 10 secondes. La valeur par défaut de l'état compliant est de 10 minutes. Pour désactiver l'intervalle d'évaluation, définissez la valeur sur never.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous vous êtes connecté au cluster hub en tant qu'utilisateur avec les privilèges cluster-admin.
  • Vous avez créé un dépôt Git dans lequel vous gérez les données de configuration de votre site personnalisé.

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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  3. Commencez les fichiers PolicyGenTemplate CRs dans le dépôt Git et apportez vos modifications.

Vérification

Vérifiez que les stratégies des clusters de rayons gérés sont contrôlées aux intervalles prévus.

  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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                                         READY   STATUS    RESTARTS        AGE
    config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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"}
    Copy to Clipboard Toggle word wrap

Créez une politique d'information du validateur qui signale la fin de l'installation et de la configuration du cluster déployé dans le cadre du Zero Touch Provisioning (ZTP). Cette politique peut être utilisée pour les déploiements de clusters OpenShift à un nœud, de clusters à trois nœuds et de clusters standard.

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
    Copy to Clipboard Toggle word wrap

    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.

Vous pouvez configurer les événements rapides PTP pour les clusters vRAN qui sont déployés à l'aide du pipeline GitOps Zero Touch Provisioning (ZTP). Utilisez les ressources personnalisées (CR) de PolicyGenTemplate comme base pour créer une hiérarchie de fichiers de configuration adaptés aux exigences spécifiques de votre site.

Conditions préalables

  • Créez un dépôt Git dans lequel vous gérez les données de configuration de votre site personnalisé.

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"
    Copy to Clipboard Toggle word wrap
  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"
      Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap
      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"
      Copy to Clipboard Toggle word wrap
  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.

OpenShift Container Platform gère la mise en cache des images à l'aide d'un registre local. Dans les cas d'utilisation de l'edge computing, les clusters sont souvent soumis à des restrictions de bande passante lorsqu'ils communiquent avec des registres d'images centralisés, ce qui peut entraîner de longs temps de téléchargement des images.

De longs temps de téléchargement sont inévitables lors du déploiement initial. Avec le temps, CRI-O risque d'effacer le répertoire /var/lib/containers/storage en cas d'arrêt inattendu. Pour remédier aux longs temps de téléchargement des images, vous pouvez créer un registre d'images local sur les clusters gérés à distance à l'aide de GitOps ZTP. Cette solution est utile dans les scénarios d'Edge computing où les clusters sont déployés à la périphérie du réseau.

Avant de pouvoir configurer le registre d'images local avec GitOps ZTP, vous devez configurer le partitionnement des disques dans le CR SiteConfig que vous utilisez pour installer le cluster géré à distance. Après l'installation, vous configurez le registre d'images local à l'aide d'un CR PolicyGenTemplate. Ensuite, le pipeline ZTP crée des CR de volume persistant (PV) et de revendication de volume persistant (PVC) et corrige la configuration imageregistry.

Note

Le registre d'images local ne peut être utilisé que pour les images d'applications utilisateur et ne peut pas être utilisé pour les images d'opérateurs OpenShift Container Platform ou Operator Lifecycle Manager.

Configurer le partitionnement du disque pour un cluster géré à l'aide d'un CR SiteConfig et du ZTP GitOps. Les détails de la partition du disque dans le CR SiteConfig doivent correspondre au disque sous-jacent.

Note

Utilisez des noms persistants pour les périphériques afin d'éviter que les noms de périphériques tels que /dev/sda et /dev/sdb ne soient échangés à chaque redémarrage. Vous pouvez utiliser rootDeviceHints pour choisir le périphérique de démarrage et utiliser ensuite le même périphérique pour d'autres partitionnements.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous vous êtes connecté au cluster hub en tant qu'utilisateur avec les privilèges cluster-admin.
  • Vous avez créé un dépôt Git dans lequel vous gérez les données de configuration de votre site personnalisé pour l'utiliser avec GitOps Zero Touch Provisioning (ZTP).

Procédure

  1. Ajoutez le fichier YAML suivant, qui décrit le partitionnement du disque hôte, au fichier SiteConfig CR que vous utilisez pour installer le cluster géré :

    nodes:
        rootDeviceHints:
          wwn: "0x62cea7f05c98c2002708a0a22ff480ea"
        diskPartition:
          - device: /dev/disk/by-id/wwn-0x62cea7f05c98c2002708a0a22ff480ea 
    1
    
            partitions:
              - mount_point: /var/imageregistry
                size: 102500 
    2
    
                start: 344844 
    3
    Copy to Clipboard Toggle word wrap
    1
    Ce paramètre dépend du matériel. Il peut s'agir d'un numéro de série ou d'un nom d'appareil. La valeur doit correspondre à la valeur définie pour rootDeviceHints.
    2
    La valeur minimale pour size est de 102500 MiB.
    3
    La valeur minimale pour start est de 25000 MiB. La valeur totale de size et start ne doit pas dépasser la taille du disque, sinon l'installation échouera.
  2. Sauvegardez le CR SiteConfig et mettez-le dans le répertoire de configuration du site.

Le pipeline ZTP approvisionne le cluster à l'aide de SiteConfig CR et configure la partition du disque.

Utilisez les CR PolicyGenTemplate (PGT) pour appliquer les CR nécessaires à la configuration du registre d'images et à la correction de la configuration imageregistry.

Conditions préalables

  • Vous avez configuré une partition de disque dans le cluster géré.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous vous êtes connecté au cluster hub en tant qu'utilisateur avec les privilèges cluster-admin.
  • Vous avez créé un dépôt Git dans lequel vous gérez les données de configuration de votre site personnalisé pour l'utiliser avec GitOps Zero Touch Provisioning (ZTP).

Procédure

  1. Configurez la classe de stockage, la revendication de volume persistant, le volume persistant et la configuration du registre d'images dans le CR PolicyGenTemplate approprié. Par exemple, pour configurer un site individuel, ajoutez le fichier YAML suivant au fichier example-sno-site.yaml:

    sourceFiles:
      # storage class
      - fileName: StorageClass.yaml
        policyName: "sc-for-image-registry"
        metadata:
          name: image-registry-sc
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100" 
    1
    
      # persistent volume claim
      - fileName: StoragePVC.yaml
        policyName: "pvc-for-image-registry"
        metadata:
          name: image-registry-pvc
          namespace: openshift-image-registry
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
        spec:
          accessModes:
            - ReadWriteMany
          resources:
            requests:
              storage: 100Gi
          storageClassName: image-registry-sc
          volumeMode: Filesystem
      # persistent volume
      - fileName: ImageRegistryPV.yaml 
    2
    
        policyName: "pv-for-image-registry"
        metadata:
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
      - fileName: ImageRegistryConfig.yaml
        policyName: "config-for-image-registry"
        complianceType: musthave
        metadata:
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
        spec:
          storage:
            pvc:
              claim: "image-registry-pvc"
    Copy to Clipboard Toggle word wrap
    1
    Définissez la valeur appropriée pour ztp-deploy-wave selon que vous configurez les registres d'images au niveau du site, du commun ou du groupe. ztp-deploy-wave: "100" convient au développement ou aux tests car il vous permet de regrouper les fichiers source référencés.
    2
    Dans ImageRegistryPV.yaml, assurez-vous que le champ spec.local.path est défini à /var/imageregistry pour correspondre à la valeur définie pour le champ mount_point dans le CR SiteConfig.
    Important

    Ne définissez pas complianceType: mustonlyhave pour la configuration - fileName: ImageRegistryConfig.yaml. Cela peut faire échouer le déploiement du pod de registre.

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

Vérification

Suivez les étapes suivantes pour résoudre les erreurs du registre d'images local sur les clusters gérés :

  • Vérifiez que la connexion au registre est réussie lorsque vous êtes connecté au cluster géré. Exécutez les commandes suivantes :

    1. Exporter le nom du cluster géré :

      $ cluster=<nom_du_cluster_géré>
      Copy to Clipboard Toggle word wrap
    2. Obtenir les détails du cluster géré kubeconfig:

      $ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
      Copy to Clipboard Toggle word wrap
    3. Télécharger et exporter le cluster kubeconfig:

      $ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
      Copy to Clipboard Toggle word wrap
    4. Vérifiez l'accès au registre d'images à partir du cluster géré. Voir "Accès au registre".
  • Vérifiez que le CRD Config de l'instance du groupe imageregistry.operator.openshift.io ne signale pas d'erreurs. Exécutez la commande suivante en vous connectant au cluster géré :

    $ oc get image.config.openshift.io cluster -o yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: config.openshift.io/v1
    kind: Image
    metadata:
      annotations:
        include.release.openshift.io/ibm-cloud-managed: "true"
        include.release.openshift.io/self-managed-high-availability: "true"
        include.release.openshift.io/single-node-developer: "true"
        release.openshift.io/create-only: "true"
      creationTimestamp: "2021-10-08T19:02:39Z"
      generation: 5
      name: cluster
      resourceVersion: "688678648"
      uid: 0406521b-39c0-4cda-ba75-873697da75a4
    spec:
      additionalTrustedCA:
        name: acm-ice
    Copy to Clipboard Toggle word wrap

  • Vérifiez que le site PersistentVolumeClaim du cluster géré contient des données. Exécutez la commande suivante en vous connectant au cluster géré :

    $ oc get pv image-registry-sc
    Copy to Clipboard Toggle word wrap
  • Vérifiez que le pod registry* est en cours d'exécution et qu'il se trouve dans l'espace de noms openshift-image-registry.

    $ oc get pods -n openshift-image-registry | grep registry*
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    cluster-image-registry-operator-68f5c9c589-42cfg   1/1     Running     0          8d
    image-registry-5f8987879-6nx6h                     1/1     Running     0          8d
    Copy to Clipboard Toggle word wrap

  • Vérifiez que la partition du disque sur le cluster géré est correcte :

    1. Ouvrez un shell de débogage sur le cluster géré :

      $ oc debug node/sno-1.example.com
      Copy to Clipboard Toggle word wrap
    2. Exécutez lsblk pour vérifier les partitions du disque hôte :

      sh-4.4# lsblk
      NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
      sda      8:0    0 446.6G  0 disk
        |-sda1   8:1    0     1M  0 part
        |-sda2   8:2    0   127M  0 part
        |-sda3   8:3    0   384M  0 part /boot
        |-sda4   8:4    0 336.3G  0 part /sysroot
        `-sda5   8:5    0 100.1G  0 part /var/imageregistry 
      1
      
      sdb      8:16   0 446.6G  0 disk
      sr0     11:0    1   104M  0 rom
      Copy to Clipboard Toggle word wrap
      1
      /var/imageregistry indique que le disque est correctement partitionné.

Vous pouvez configurer des événements matériels bare-metal pour les clusters vRAN qui sont déployés à l'aide du pipeline Zero Touch Provisioning (ZTP) de GitOps.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
  • Créez un dépôt Git dans lequel vous gérez les données de configuration de votre site personnalisé.

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"
    Copy to Clipboard Toggle word wrap
  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"
    Copy to Clipboard Toggle word wrap
  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"
    Copy to Clipboard Toggle word wrap
    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>"
    Copy to Clipboard Toggle word wrap

Topology Aware Lifecycle Manager prend en charge les fonctions partielles du modèle de cluster de hub de Red Hat Advanced Cluster Management (RHACM) dans les politiques de configuration utilisées avec GitOps ZTP.

Les modèles de grappes côté hub vous permettent de définir des politiques de configuration qui peuvent être dynamiquement adaptées aux grappes cibles. Il n'est donc pas nécessaire de créer des politiques distinctes pour de nombreux clusters ayant des configurations similaires mais des valeurs différentes.

Important

Les modèles de politique sont limités au même espace de noms que celui dans lequel la politique est définie. Cela signifie que vous devez créer les objets référencés dans le modèle de hub dans le même espace de noms que celui où la politique est créée.

Les fonctions de modèle de concentrateur suivantes sont disponibles pour une utilisation dans GitOps ZTP avec TALM :

  • fromConfigmap renvoie la valeur de la clé de données fournie dans la ressource nommée ConfigMap.

    Note

    La taille des CR ConfigMap est limitée à 1 MiB. La taille effective des CR ConfigMap est encore limitée par l'annotation last-applied-configuration. Pour éviter la limite de last-applied-configuration, ajoutez l'annotation suivante au modèle ConfigMap:

    argocd.argoproj.io/sync-options: Replace=true
    Copy to Clipboard Toggle word wrap
  • base64enc renvoie la valeur encodée en base64 de la chaîne d'entrée
  • base64dec renvoie la valeur décodée de la chaîne d'entrée encodée en base64
  • indent renvoie la chaîne d'entrée avec les espaces d'indentation ajoutés
  • autoindent renvoie la chaîne d'entrée avec des espaces d'indentation ajoutés en fonction de l'espacement utilisé dans le modèle parent
  • toInt convertit et renvoie la valeur entière de la valeur d'entrée
  • toBool convertit la chaîne d'entrée en une valeur booléenne et renvoie la valeur booléenne

Diverses fonctions de la communauté Open source sont également disponibles pour une utilisation avec GitOps ZTP.

21.9.10.1. Exemples de modèles de concentrateurs

Les exemples de code suivants sont des modèles de concentrateur valides. Chacun de ces modèles renvoie des valeurs provenant du CR ConfigMap portant le nom test-config dans l'espace de noms default.

  • Renvoie la valeur avec la clé common-key:

    {{hub fromConfigMap "default" "test-config" "common-key" hub}}
    Copy to Clipboard Toggle word wrap
  • Renvoie une chaîne en utilisant la valeur concaténée du champ .ManagedClusterName et la chaîne -name:

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) hub}}
    Copy to Clipboard Toggle word wrap
  • Crée et renvoie une valeur booléenne à partir de la valeur concaténée du champ .ManagedClusterName et de la chaîne de caractères -name:

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) | toBool hub}}
    Copy to Clipboard Toggle word wrap
  • Crée et renvoie une valeur entière à partir de la valeur concaténée du champ .ManagedClusterName et de la chaîne de caractères -name:

    {{hub (printf "%s-name" .ManagedClusterName) | fromConfigMap "default" "test-config" | toInt hub}}
    Copy to Clipboard Toggle word wrap

Vous pouvez gérer les NIC des hôtes dans un seul CR ConfigMap et utiliser les modèles de cluster de hub pour remplir les valeurs NIC personnalisées dans les polices générées qui sont appliquées aux hôtes du cluster. L'utilisation de modèles de cluster de concentrateurs dans les CR PolicyGenTemplate (PGT) signifie qu'il n'est pas nécessaire de créer plusieurs CR PGT pour chaque site.

L'exemple suivant vous montre comment utiliser un seul CR ConfigMap pour gérer les NIC des hôtes du cluster et les appliquer au cluster en tant que polices en utilisant un seul CR de site PolicyGenTemplate.

Note

Lorsque vous utilisez la fonction fromConfigmap, la variable printf n'est disponible que pour les champs clés de la ressource modèle data. Vous ne pouvez pas l'utiliser pour les champs name et namespace.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous vous êtes connecté au cluster hub en tant qu'utilisateur avec les privilèges cluster-admin.
  • Vous avez créé un dépôt Git dans lequel 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 l'application GitOps ZTP ArgoCD.

Procédure

  1. Créez une ressource ConfigMap qui décrit les cartes réseau d'un groupe d'hôtes. Par exemple :

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: sriovdata
      namespace: ztp-site
      annotations:
        argocd.argoproj.io/sync-options: Replace=true 
    1
    
    data:
      example-sno-du_fh-numVfs: "8"
      example-sno-du_fh-pf: ens1f0
      example-sno-du_fh-priority: "10"
      example-sno-du_fh-vlan: "140"
      example-sno-du_mh-numVfs: "8"
      example-sno-du_mh-pf: ens3f0
      example-sno-du_mh-priority: "10"
      example-sno-du_mh-vlan: "150"
    Copy to Clipboard Toggle word wrap
    1
    L'annotation argocd.argoproj.io/sync-options n'est requise que si le site ConfigMap a une taille supérieure à 1 Mio.
    Note

    Le site ConfigMap doit se trouver dans le même espace de noms que la politique pour laquelle la substitution du modèle de concentrateur a été effectuée.

  2. Commencer le CR ConfigMap dans Git, puis le pousser vers le dépôt Git contrôlé par l'application Argo CD.
  3. Créez une PGT CR de site qui utilise des modèles pour extraire les données requises de l'objet ConfigMap. En voici un exemple :

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "site"
      namespace: "ztp-site"
    spec:
      remediationAction: inform
      bindingRules:
        group-du-sno: ""
      mcp: "master"
      sourceFiles:
        - fileName: SriovNetwork.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nw-du-fh"
          spec:
            resourceName: du_fh
            vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-vlan" .ManagedClusterName) | toInt hub}}'
        - fileName: SriovNetworkNodePolicy.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nnp-du-fh"
          spec:
            deviceType: netdevice
            isRdma: true
            nicSelector:
              pfNames:
              - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-pf" .ManagedClusterName) | autoindent hub}}'
            numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-numVfs" .ManagedClusterName) | toInt hub}}'
            priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-priority" .ManagedClusterName) | toInt hub}}'
            resourceName: du_fh
        - fileName: SriovNetwork.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nw-du-mh"
          spec:
            resourceName: du_mh
            vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-vlan" .ManagedClusterName) | toInt hub}}'
        - fileName: SriovNetworkNodePolicy.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nnp-du-mh"
          spec:
            deviceType: vfio-pci
            isRdma: false
            nicSelector:
              pfNames:
              - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-pf" .ManagedClusterName)  hub}}'
            numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-numVfs" .ManagedClusterName) | toInt hub}}'
            priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-priority" .ManagedClusterName) | toInt hub}}'
            resourceName: du_mh
    Copy to Clipboard Toggle word wrap
  4. Commencer le site PolicyGenTemplate CR dans Git et le pousser vers le dépôt Git qui est surveillé par l'application ArgoCD.

    Note

    Les modifications ultérieures apportées à la CR ConfigMap référencée ne sont pas automatiquement synchronisées avec les politiques appliquées. Vous devez synchroniser manuellement les nouvelles modifications de ConfigMap pour mettre à jour les PolicyGenTemplate CR existants. Voir "Synchronisation des nouvelles modifications du ConfigMap avec les CR PolicyGenTemplate existantes".

Vous pouvez gérer les ID de VLAN pour les clusters gérés dans un seul ConfigMap CR et utiliser les modèles de cluster de hub pour remplir les ID de VLAN dans les polices générées qui sont appliquées aux clusters.

L'exemple suivant montre comment gérer les ID VLAN dans un seul ConfigMap CR et les appliquer dans des polices de cluster individuelles en utilisant un seul PolicyGenTemplate group CR.

Note

Lorsque vous utilisez la fonction fromConfigmap, la variable printf n'est disponible que pour les champs clés de la ressource modèle data. Vous ne pouvez pas l'utiliser pour les champs name et namespace.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous vous êtes connecté au cluster hub en tant qu'utilisateur avec les privilèges cluster-admin.
  • Vous avez créé 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 l'application Argo CD.

Procédure

  1. Créez un CR ConfigMap qui décrit les ID VLAN pour un groupe d'hôtes du cluster. Par exemple :

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: site-data
      namespace: ztp-group
      annotations:
        argocd.argoproj.io/sync-options: Replace=true 
    1
    
    data:
      site-1-vlan: "101"
      site-2-vlan: "234"
    Copy to Clipboard Toggle word wrap
    1
    L'annotation argocd.argoproj.io/sync-options n'est requise que si le site ConfigMap a une taille supérieure à 1 Mio.
    Note

    Le site ConfigMap doit se trouver dans le même espace de noms que la politique pour laquelle la substitution du modèle de concentrateur a été effectuée.

  2. Commencer le CR ConfigMap dans Git, puis le pousser vers le dépôt Git contrôlé par l'application Argo CD.
  3. Créez un groupe PGT CR qui utilise un modèle de concentrateur pour extraire les ID VLAN requis de l'objet ConfigMap. Par exemple, ajoutez l'extrait YAML suivant au groupe PGT CR :

    - fileName: SriovNetwork.yaml
        policyName: "config-policy"
        metadata:
          name: "sriov-nw-du-mh"
          annotations:
            ran.openshift.io/ztp-deploy-wave: "10"
        spec:
          resourceName: du_mh
          vlan: '{{hub fromConfigMap "" "site-data" (printf "%s-vlan" .ManagedClusterName) | toInt hub}}'
    Copy to Clipboard Toggle word wrap
  4. Commencer le groupe PolicyGenTemplate CR dans Git, puis pousser vers le dépôt Git surveillé par l'application Argo CD.

    Note

    Les modifications ultérieures apportées à la CR ConfigMap référencée ne sont pas automatiquement synchronisées avec les politiques appliquées. Vous devez synchroniser manuellement les nouvelles modifications de ConfigMap pour mettre à jour les PolicyGenTemplate CR existants. Voir "Synchronisation des nouvelles modifications du ConfigMap avec les CR PolicyGenTemplate existantes".

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous vous êtes connecté au cluster hub en tant qu'utilisateur avec les privilèges cluster-admin.
  • Vous avez créé un CR PolicyGenTemplate qui tire des informations d'un CR ConfigMap à l'aide de modèles de grappes de nœuds.

Procédure

  1. Mettez à jour le contenu de votre ConfigMap CR, et appliquez les changements dans le cluster hub.
  2. Pour synchroniser le contenu de la CR ConfigMap mise à jour avec la politique déployée, effectuez l'une des opérations suivantes :

    1. Option 1 : Supprimer la politique existante. ArgoCD utilise la commande PolicyGenTemplate CR pour recréer immédiatement la politique supprimée. Par exemple, exécutez la commande suivante :

      oc delete policy <policy_name> -n <policy_namespace> $ oc delete policy <policy_name>
      Copy to Clipboard Toggle word wrap
    2. Option 2 : Appliquer une annotation spéciale policy.open-cluster-management.io/trigger-update à la police avec une valeur différente à chaque fois que vous mettez à jour le site ConfigMap. Par exemple :

      $ oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"
      Copy to Clipboard Toggle word wrap
      Note

      Vous devez appliquer la politique mise à jour pour que les modifications soient prises en compte. Pour plus d'informations, voir Annotation spéciale pour le retraitement.

  3. Facultatif : si elle existe, supprimez la CR ClusterGroupUpdate qui contient la politique. Par exemple :

    oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>
    Copy to Clipboard Toggle word wrap
    1. Créez un nouveau CR ClusterGroupUpdate qui inclut la politique à appliquer avec les changements mis à jour de ConfigMap. Par exemple, ajoutez le fichier YAML suivant au fichier cgr-example.yaml:

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: <cgr_name>
        namespace: <policy_namespace>
      spec:
        managedPolicies:
          - <managed_policy>
        enable: true
        clusters:
        - <managed_cluster_1>
        - <managed_cluster_2>
        remediationStrategy:
          maxConcurrency: 2
          timeout: 240
      Copy to Clipboard Toggle word wrap
    2. Appliquer la politique mise à jour :

      $ oc apply -f cgr-example.yaml
      Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat