21.12. Extension des clusters OpenShift à nœud unique avec GitOps ZTP

Procédure

1. Vérifiez les paramètres du sélecteur de nœud du démon de l'opérateur PTP sur l'un des clusters de rayons :

   $ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq

   Copy to Clipboard Toggle word wrap

   Exemple de sortie pour l'opérateur PTP

   {\i1}"daemonNodeSelector":{\i1}"node-role.kubernetes.io/master":{\i1}"\N- \N"\N"\N"}} 

   1

   Copy to Clipboard Toggle word wrap

   1

   Si le sélecteur de nœud est défini sur master, le rayon a été déployé avec la version du plugin ZTP qui nécessite des modifications.

2. Vérifiez les paramètres du sélecteur de nœud démon de l'opérateur SR-IOV sur l'un des clusters de rayons :

   $  oc get sriovoperatorconfig/default -n \
   openshift-sriov-network-operator -ojsonpath='{.spec}' | jq

   Copy to Clipboard Toggle word wrap

   Exemple de sortie pour l'opérateur SR-IOV

   {\aemonNodeSelector":{"node-role.kubernetes.io/worker":\N"\N"},\N "disableDrain":false,\N "enableInjector":true,\N "enableOperatorWebhook":true} 

   1

   Copy to Clipboard Toggle word wrap

   1

   Si le sélecteur de nœud est défini sur master, le rayon a été déployé avec la version du plugin ZTP qui nécessite des modifications.

3. Dans la stratégie de groupe, ajoutez les entrées complianceType et spec suivantes :

   spec:
       - fileName: PtpOperatorConfig.yaml
         policyName: "config-policy"
         complianceType: mustonlyhave
         spec:
           daemonNodeSelector:
             node-role.kubernetes.io/worker: ""
       - fileName: SriovOperatorConfig.yaml
         policyName: "config-policy"
         complianceType: mustonlyhave
         spec:
           configDaemonNodeSelector:
             node-role.kubernetes.io/worker: ""

   Copy to Clipboard Toggle word wrap
   Important

   La modification du champ daemonNodeSelector entraîne une perte temporaire de synchronisation PTP et une perte de connectivité SR-IOV.

4. Commencer les changements dans Git, puis pousser vers le dépôt Git surveillé par l'application GitOps ZTP ArgoCD.

Procédure

1. Créez le modèle de politique suivant :

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "example-sno-workers"
     namespace: "example-sno"
   spec:
     bindingRules:
       sites: "example-sno" 

   1

   
     mcp: "worker" 

   2

   
     sourceFiles:
       - fileName: MachineConfigGeneric.yaml 

   3

   
         policyName: "config-policy"
         metadata:
           labels:
             machineconfiguration.openshift.io/role: worker
           name: enable-workload-partitioning
         spec:
           config:
             storage:
               files:
               - contents:
                   source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMyIgfQo=
                 mode: 420
                 overwrite: true
                 path: /etc/crio/crio.conf.d/01-workload-partitioning
                 user:
                   name: root
               - contents:
                   source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTMiCiAgfQp9Cg==
                 mode: 420
                 overwrite: true
                 path: /etc/kubernetes/openshift-workload-pinning
                 user:
                   name: root
       - fileName: PerformanceProfile.yaml
         policyName: "config-policy"
         metadata:
           name: openshift-worker-node-performance-profile
         spec:
           cpu: 

   4

   
             isolated: "4-47"
             reserved: "0-3"
           hugepages:
             defaultHugepagesSize: 1G
             pages:
               - size: 1G
                 count: 32
           realTimeKernel:
             enabled: true
       - fileName: TunedPerformancePatch.yaml
         policyName: "config-policy"
         metadata:
           name: performance-patch-worker
         spec:
           profile:
             - name: performance-patch-worker
               data: |
                 [main]
                 summary=Configuration changes profile inherited from performance created tuned
                 include=openshift-node-performance-openshift-worker-node-performance-profile
                 [bootloader]
                 cmdline_crash=nohz_full=4-47 

   5

   
                 [sysctl]
                 kernel.timer_migration=1
                 [scheduler]
                 group.ice-ptp=0:f:10:*:ice-ptp.*
                 [service]
                 service.stalld=start,enable
                 service.chronyd=stop,disable
           recommend:
           - profile: performance-patch-worker

   Copy to Clipboard Toggle word wrap

   1

   Les politiques sont appliquées à tous les clusters portant cette étiquette.

   2

   Le champ MCP doit être défini comme worker.

   3

   Ce CR générique MachineConfig est utilisé pour configurer le partitionnement de la charge de travail sur le nœud de travail.

   4

   Les champs cpu.isolated et cpu.reserved doivent être configurés pour chaque plate-forme matérielle.

   5

   L'ensemble d'unités centrales cmdline_crash doit correspondre à l'ensemble d'unités centrales cpu.isolated dans la section PerformanceProfile.

   Un CR générique MachineConfig est utilisé pour configurer le partitionnement de la charge de travail sur le nœud de travail. Vous pouvez générer le contenu des fichiers de configuration crio et kubelet.

2. Ajoutez le modèle de politique créé au dépôt Git surveillé par l'application ArgoCD policies.
3. Ajouter la politique dans le fichier kustomization.yaml.
4. Commencer les changements dans Git, puis pousser vers le dépôt Git surveillé par l'application GitOps ZTP ArgoCD.

5. Pour remédier aux nouvelles politiques dans votre cluster de rayons, créez une ressource personnalisée TALM :

   $ cat <<EOF | oc apply -f -
   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: example-sno-worker-policies
     namespace: default
   spec:
     backup: false
     clusters:
     - example-sno
     enable: true
     managedPolicies:
     - group-du-sno-config-policy
     - example-sno-workers-config-policy
     - example-sno-config-policy
     preCaching: false
     remediationStrategy:
       maxConcurrency: 1
   EOF

   Copy to Clipboard Toggle word wrap

Procédure

1. Si vous avez déployé votre cluster en utilisant le manifeste example-sno.yaml SiteConfig , ajoutez votre nouveau nœud de travail à la liste spec.clusters['example-sno'].nodes:

   nodes:
   - hostName: "example-node2.example.com"
     role: "worker"
     bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
     bmcCredentialsName:
       name: "example-node2-bmh-secret"
     bootMACAddress: "AA:BB:CC:DD:EE:11"
     bootMode: "UEFI"
     nodeNetwork:
       interfaces:
         - name: eno1
           macAddress: "AA:BB:CC:DD:EE:11"
       config:
         interfaces:
           - name: eno1
             type: ethernet
             state: up
             macAddress: "AA:BB:CC:DD:EE:11"
             ipv4:
               enabled: false
             ipv6:
               enabled: true
               address:
               - ip: 1111:2222:3333:4444::1
                 prefix-length: 64
         dns-resolver:
           config:
             search:
             - example.com
             server:
             - 1111:2222:3333:4444::2
         routes:
           config:
           - destination: ::/0
             next-hop-interface: eno1
             next-hop-address: 1111:2222:3333:4444::1
             table-id: 254

   Copy to Clipboard Toggle word wrap

2. Créez un secret d'authentification BMC pour le nouvel hôte, référencé par le champ bmcCredentialsName dans la section spec.nodes de votre fichier SiteConfig:

   apiVersion: v1
   data:
     password: "password"
     username: "username"
   kind: Secret
   metadata:
     name: "example-node2-bmh-secret"
     namespace: example-sno
   type: Opaque

   Copy to Clipboard Toggle word wrap

3. Commencer les changements dans Git, puis pousser vers le dépôt Git qui est surveillé par l'application GitOps ZTP ArgoCD.

   Lorsque l'application ArgoCD cluster se synchronise, deux nouveaux manifestes apparaissent sur le hub cluster généré par le plugin ZTP :

   • BareMetalHost

   • NMStateConfig

     Important

     Le champ cpuset ne doit pas être configuré pour le nœud de travail. Le partitionnement de la charge de travail pour les nœuds de travail est ajouté par le biais de stratégies de gestion une fois l'installation du nœud terminée.