21.7. Valider le réglage d'un cluster OpenShift à nœud unique pour les charges de travail des applications vDU

Procédure

1. Vérifiez que les sources OperatorHub par défaut sont désactivées. Exécutez la commande suivante :

   $ oc get operatorhub cluster -o yaml

   Exemple de sortie

   spec:
       disableAllDefaultSources: true

2. Vérifiez que toutes les ressources CatalogSource requises sont annotées pour le partitionnement de la charge de travail (PreferredDuringScheduling) en exécutant la commande suivante :

   $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

   Exemple de sortie

   certified-operators -- {"effect": "PreferredDuringScheduling"}
   community-operators -- {"effect": "PreferredDuringScheduling"}
   ran-operators 1
   redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
   redhat-operators -- {"effect": "PreferredDuringScheduling"}

   1

   CatalogSource les ressources qui ne sont pas annotées sont également renvoyées. Dans cet exemple, la ressource ran-operators CatalogSource n'est pas annotée et n'a pas l'annotation PreferredDuringScheduling.

   Note

   Dans un cluster vDU correctement configuré, une seule source de catalogue annotée est répertoriée.

3. Vérifiez que tous les espaces de noms d'opérateurs OpenShift Container Platform applicables sont annotés pour le partitionnement de la charge de travail. Cela inclut tous les opérateurs installés avec le noyau d'OpenShift Container Platform et l'ensemble des opérateurs supplémentaires inclus dans la configuration de réglage DU de référence. Exécutez la commande suivante :

   $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

   Exemple de sortie

   default --
   openshift-apiserver -- management
   openshift-apiserver-operator -- management
   openshift-authentication -- management
   openshift-authentication-operator -- management

   Important

   Les opérateurs supplémentaires ne doivent pas être annotés pour le partitionnement de la charge de travail. Dans la sortie de la commande précédente, les opérateurs supplémentaires doivent être listés sans aucune valeur à droite du séparateur --.

4. Vérifiez que la configuration de ClusterLogging est correcte. Exécutez les commandes suivantes :

   1. Validez que les journaux d'entrée et de sortie appropriés sont configurés :

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      Exemple de sortie

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
        creationTimestamp: "2022-07-19T21:51:41Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "1030342"
        uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
      spec:
        inputs:
        - infrastructure: {}
          name: infra-logs
        outputs:
        - name: kafka-open
          type: kafka
          url: tcp://10.46.55.190:9092/test
        pipelines:
        - inputRefs:
          - audit
          name: audit-logs
          outputRefs:
          - kafka-open
        - inputRefs:
          - infrastructure
          name: infrastructure-logs
          outputRefs:
          - kafka-open
      ...

   2. Vérifiez que le calendrier de curation est adapté à votre application :

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      Exemple de sortie

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        creationTimestamp: "2022-07-07T18:22:56Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "235796"
        uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
      spec:
        collection:
          logs:
            fluentd: {}
            type: fluentd
        curation:
          curator:
            schedule: 30 3 * * *
          type: curator
        managementState: Managed
      ...

5. Vérifiez que la console web est désactivée (managementState: Removed) en exécutant la commande suivante :

   $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

   Exemple de sortie

   Supprimé

6. Vérifiez que chronyd est désactivé sur le nœud de cluster en exécutant les commandes suivantes :

   oc debug node/<node_name>

   Vérifiez l'état de chronyd sur le nœud :

   sh-4.4# chroot /host

   sh-4.4# systemctl status chronyd

   Exemple de sortie

   ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:chronyd(8)
               man:chrony.conf(5)

7. Vérifiez que l'interface PTP est bien synchronisée avec l'horloge primaire en utilisant une connexion shell à distance au conteneur linuxptp-daemon et à l'outil PTP Management Client (pmc) :

   1. Définissez la variable $PTP_POD_NAME avec le nom du module linuxptp-daemon en exécutant la commande suivante :

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

   2. Exécutez la commande suivante pour vérifier l'état de synchronisation du dispositif PTP :

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      Exemple de sortie

      sending: GET PORT_DATA_SET
        3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-1
          portState               SLAVE
          logMinDelayReqInterval  -4
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2
        3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-2
          portState               LISTENING
          logMinDelayReqInterval  0
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2

   3. Exécutez la commande suivante pmc pour vérifier l'état de l'horloge PTP :

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      Exemple de sortie

      sending: GET TIME_STATUS_NP
        3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
          master_offset              10 1
          ingress_time               1657275432697400530
          cumulativeScaledRateOffset +0.000000000
          scaledLastGmPhaseChange    0
          gmTimeBaseIndicator        0
          lastGmPhaseChange          0x0000'0000000000000000.0000
          gmPresent                  true 2
          gmIdentity                 3c2c30.ffff.670e00

      1

      master_offset doit se situer entre -100 et 100 ns.

      2

      Indique que l'horloge PTP est synchronisée avec un maître et que l'horloge locale n'est pas l'horloge du grand maître.

   4. Vérifiez que la valeur attendue de master offset correspondant à la valeur de /var/run/ptp4l.0.config se trouve dans le journal de linuxptp-daemon-container:

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      Exemple de sortie

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
      ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
      ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

8. Vérifiez que la configuration du SR-IOV est correcte en exécutant les commandes suivantes :

   1. Vérifiez que la valeur disableDrain de la ressource SriovOperatorConfig est définie sur true:

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      Exemple de sortie

      true

   2. Vérifiez que l'état de synchronisation de SriovNetworkNodeState est Succeeded en exécutant la commande suivante :

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      Exemple de sortie

      Succeeded

   3. Vérifier que le nombre et la configuration attendus des fonctions virtuelles (Vfs) sous chaque interface configurée pour SR-IOV sont présents et corrects dans le champ .status.interfaces. Par exemple :

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      Exemple de sortie

      apiVersion: v1
      items:
      - apiVersion: sriovnetwork.openshift.io/v1
        kind: SriovNetworkNodeState
      ...
        status:
          interfaces:
          ...
          - Vfs:
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.0
              vendor: "8086"
              vfID: 0
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.1
              vendor: "8086"
              vfID: 1
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.2
              vendor: "8086"
              vfID: 2
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.3
              vendor: "8086"
              vfID: 3
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.4
              vendor: "8086"
              vfID: 4
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.5
              vendor: "8086"
              vfID: 5
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.6
              vendor: "8086"
              vfID: 6
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.7
              vendor: "8086"
              vfID: 7

9. Vérifiez que le profil de performance du cluster est correct. Les sections cpu et hugepages varient en fonction de votre configuration matérielle. Exécutez la commande suivante :

   $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

   Exemple de sortie

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     creationTimestamp: "2022-07-19T21:51:31Z"
     finalizers:
     - foreground-deletion
     generation: 1
     name: openshift-node-performance-profile
     resourceVersion: "33558"
     uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
   spec:
     additionalKernelArgs:
     - idle=poll
     - rcupdate.rcu_normal_after_boot=0
     - efi=runtime
     cpu:
       isolated: 2-51,54-103
       reserved: 0-1,52-53
     hugepages:
       defaultHugepagesSize: 1G
       pages:
       - count: 32
         size: 1G
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/master: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/master: ""
     numa:
       topologyPolicy: restricted
     realTimeKernel:
       enabled: true
   status:
     conditions:
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Available
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Upgradeable
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Progressing
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Degraded
     runtimeClass: performance-openshift-node-performance-profile
     tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

   Note

   Les paramètres du processeur dépendent du nombre de cœurs disponibles sur le serveur et doivent être alignés sur les paramètres de partitionnement de la charge de travail. La configuration de hugepages dépend du serveur et de l'application.

10. Vérifiez que le site PerformanceProfile a été appliqué avec succès au cluster en exécutant la commande suivante :

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    Exemple de sortie

    Available -- True
    Upgradeable -- True
    Progressing -- False
    Degraded -- False

11. Vérifiez les paramètres du correctif de performance Tuned en exécutant la commande suivante :

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    Exemple de sortie

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      creationTimestamp: "2022-07-18T10:33:52Z"
      generation: 1
      name: performance-patch
      namespace: openshift-cluster-node-tuning-operator
      resourceVersion: "34024"
      uid: f9799811-f744-4179-bf00-32d4436c08fd
    spec:
      profile:
      - data: |
          [main]
          summary=Configuration changes profile inherited from performance created tuned
          include=openshift-node-performance-openshift-node-performance-profile
          [bootloader]
          cmdline_crash=nohz_full=2-23,26-47 1
          [sysctl]
          kernel.timer_migration=1
          [scheduler]
          group.ice-ptp=0:f:10:*:ice-ptp.*
          [service]
          service.stalld=start,enable
          service.chronyd=stop,disable
        name: performance-patch
      recommend:
      - machineConfigLabels:
          machineconfiguration.openshift.io/role: master
        priority: 19
        profile: performance-patch

    1

    La liste des processeurs dans cmdline=nohz_full= variera en fonction de votre configuration matérielle.

12. Vérifiez que les diagnostics de mise en réseau du cluster sont désactivés en exécutant la commande suivante :

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    Exemple de sortie

    true

13. Vérifiez que l'intervalle de maintenance de Kubelet est réglé sur un taux plus lent. Ce paramètre est défini dans la configuration de la machine containerMountNS. Exécutez la commande suivante :

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    Exemple de sortie

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

14. Vérifiez que Grafana et alertManagerMain sont désactivés et que la période de rétention de Prometheus est fixée à 24 heures en exécutant la commande suivante :

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    Exemple de sortie

    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    prometheusK8s:
       retention: 24h

    1. Utilisez les commandes suivantes pour vérifier que les routes Grafana et alertManagerMain ne sont pas trouvées dans le cluster :

       $ oc get route -n openshift-monitoring alertmanager-main

       $ oc get route -n openshift-monitoring grafana

       Les deux requêtes devraient renvoyer des messages à l'adresse Error from server (NotFound).

15. Vérifiez qu'il y a un minimum de 4 CPUs alloués comme reserved pour chacun des arguments de ligne de commande PerformanceProfile, Tuned performance-patch, workload partitioning, et kernel en exécutant la commande suivante :

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    Exemple de sortie

    0-3

    Note

    En fonction de votre charge de travail, vous pouvez avoir besoin d'allouer des unités centrales réservées supplémentaires.