Procédure

1. Utilisez la commande oc adm pour extraire l'URL de l'image du site driver-toolkit correspondant à une certaine version :

   • Pour une image x86, entrez la commande suivante :

     $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.12.z-x86_64 --image-for=driver-toolkit

   • Pour une image ARM, entrez la commande suivante :

     $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.12.z-aarch64 --image-for=driver-toolkit

   Exemple de sortie

   quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0fd84aee79606178b6561ac71f8540f404d518ae5deff45f6d6ac8f02636c7f4

2. Obtenez cette image en utilisant un pull secret valide, tel que le pull secret requis pour installer OpenShift Container Platform :

   $ podman pull --authfile=path/to/pullsecret.json quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:<SHA>

1. Le YAML définit un ImageStream pour stocker l'image du conteneur du pilote simple-kmod et un BuildConfig pour construire le conteneur. Enregistrez ce YAML sous 0000-buildconfig.yaml.template.

   apiVersion: image.openshift.io/v1
   kind: ImageStream
   metadata:
     labels:
       app: simple-kmod-driver-container
     name: simple-kmod-driver-container
     namespace: simple-kmod-demo
   spec: {}
   ---
   apiVersion: build.openshift.io/v1
   kind: BuildConfig
   metadata:
     labels:
       app: simple-kmod-driver-build
     name: simple-kmod-driver-build
     namespace: simple-kmod-demo
   spec:
     nodeSelector:
       node-role.kubernetes.io/worker: ""
     runPolicy: "Serial"
     triggers:
       - type: "ConfigChange"
       - type: "ImageChange"
     source:
       dockerfile: |
         ARG DTK
         FROM ${DTK} as builder
   
         ARG KVER
   
         WORKDIR /build/
   
         RUN git clone https://github.com/openshift-psap/simple-kmod.git
   
         WORKDIR /build/simple-kmod
   
         RUN make all install KVER=${KVER}
   
         FROM registry.redhat.io/ubi8/ubi-minimal
   
         ARG KVER
   
         # Required for installing `modprobe`
         RUN microdnf install kmod
   
         COPY --from=builder /lib/modules/${KVER}/simple-kmod.ko /lib/modules/${KVER}/
         COPY --from=builder /lib/modules/${KVER}/simple-procfs-kmod.ko /lib/modules/${KVER}/
         RUN depmod ${KVER}
     strategy:
       dockerStrategy:
         buildArgs:
           - name: KMODVER
             value: DEMO
             # $ oc adm release info quay.io/openshift-release-dev/ocp-release:<cluster version>-x86_64 --image-for=driver-toolkit
           - name: DTK
             value: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:34864ccd2f4b6e385705a730864c04a40908e57acede44457a783d739e377cae
           - name: KVER
             value: 4.18.0-372.26.1.el8_6.x86_64
     output:
       to:
         kind: ImageStreamTag
         name: simple-kmod-driver-container:demo

2. Remplacez "DRIVER_TOOLKIT_IMAGE" par l'image du driver toolkit correspondant à la version d'OpenShift Container Platform que vous utilisez, à l'aide des commandes suivantes.

   $ OCP_VERSION=$(oc get clusterversion/version -ojsonpath={.status.desired.version})

   $ DRIVER_TOOLKIT_IMAGE=$(oc adm release info $OCP_VERSION --image-for=driver-toolkit)

   $ sed "s#DRIVER_TOOLKIT_IMAGE#${DRIVER_TOOLKIT_IMAGE}#" 0000-buildconfig.yaml.template > 0000-buildconfig.yaml

3. Créer le flux d'images et la configuration de construction avec

   $ oc create -f 0000-buildconfig.yaml

4. Une fois le pod de construction terminé avec succès, déployez l'image du conteneur de pilote sous la forme d'un fichier DaemonSet.

   1. Le conteneur de pilote doit être exécuté avec le contexte de sécurité privilégié afin de charger les modules du noyau sur l'hôte. Le fichier YAML suivant contient les règles RBAC et le site DaemonSet pour l'exécution du conteneur de pilote. Enregistrez ce fichier YAML sous 1000-drivercontainer.yaml.

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: simple-kmod-driver-container
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: simple-kmod-driver-container
      rules:
      - apiGroups:
        - security.openshift.io
        resources:
        - securitycontextconstraints
        verbs:
        - use
        resourceNames:
        - privileged
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: simple-kmod-driver-container
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: simple-kmod-driver-container
      subjects:
      - kind: ServiceAccount
        name: simple-kmod-driver-container
      userNames:
      - system:serviceaccount:simple-kmod-demo:simple-kmod-driver-container
      ---
      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: simple-kmod-driver-container
      spec:
        selector:
          matchLabels:
            app: simple-kmod-driver-container
        template:
          metadata:
            labels:
              app: simple-kmod-driver-container
          spec:
            serviceAccount: simple-kmod-driver-container
            serviceAccountName: simple-kmod-driver-container
            containers:
            - image: image-registry.openshift-image-registry.svc:5000/simple-kmod-demo/simple-kmod-driver-container:demo
              name: simple-kmod-driver-container
              imagePullPolicy: Always
              command: [sleep, infinity]
              lifecycle:
                postStart:
                  exec:
                    command: ["modprobe", "-v", "-a" , "simple-kmod", "simple-procfs-kmod"]
                preStop:
                  exec:
                    command: ["modprobe", "-r", "-a" , "simple-kmod", "simple-procfs-kmod"]
              securityContext:
                privileged: true
            nodeSelector:
              node-role.kubernetes.io/worker: ""

   2. Créer les règles RBAC et le jeu de démons :

      $ oc create -f 1000-drivercontainer.yaml

5. Une fois que les pods fonctionnent sur les nœuds de travail, vérifiez que le module du noyau simple_kmod est chargé avec succès sur les machines hôtes avec lsmod.

   1. Vérifiez que les modules sont en cours d'exécution :

      $ oc get pod -n simple-kmod-demo

      Exemple de sortie

      NAME                                 READY   STATUS      RESTARTS   AGE
      simple-kmod-driver-build-1-build     0/1     Completed   0          6m
      simple-kmod-driver-container-b22fd   1/1     Running     0          40s
      simple-kmod-driver-container-jz9vn   1/1     Running     0          40s
      simple-kmod-driver-container-p45cc   1/1     Running     0          40s

   2. Exécutez la commande lsmod dans le conteneur de pilotes :

      $ oc exec -it pod/simple-kmod-driver-container-p45cc -- lsmod | grep simple

      Exemple de sortie

      simple_procfs_kmod     16384  0
      simple_kmod            16384  0

Procédure

1. Créer un espace de noms pour l'opérateur BDNF.

   1. Créez la ressource personnalisée (CR) Namespace suivante qui définit l'espace de noms openshift-nfd, puis enregistrez le YAML dans le fichier nfd-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-nfd

   2. Créez l'espace de noms en exécutant la commande suivante :

      $ oc create -f nfd-namespace.yaml

2. Installez l'opérateur NFD dans l'espace de noms que vous avez créé à l'étape précédente en créant les objets suivants :

   1. Créez le CR OperatorGroup suivant et enregistrez le YAML dans le fichier nfd-operatorgroup.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        generateName: openshift-nfd-
        name: openshift-nfd
        namespace: openshift-nfd
      spec:
        targetNamespaces:
        - openshift-nfd

   2. Créez le CR OperatorGroup en exécutant la commande suivante :

      $ oc create -f nfd-operatorgroup.yaml

   3. Créez le CR Subscription suivant et enregistrez le YAML dans le fichier nfd-sub.yaml:

      Exemple d'abonnement

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: nfd
        namespace: openshift-nfd
      spec:
        channel: "stable"
        installPlanApproval: Automatic
        name: nfd
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   4. Créez l'objet d'abonnement en exécutant la commande suivante :

      $ oc create -f nfd-sub.yaml

   5. Modification du projet openshift-nfd:

      $ oc project openshift-nfd

Procédure

1. Dans la console Web OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Choisissez Node Feature Discovery dans la liste des opérateurs disponibles, puis cliquez sur Install.
3. Sur la page Install Operator, sélectionnez A specific namespace on the cluster, puis cliquez sur Install. Vous ne devez pas créer d'espace de noms car il est créé pour vous.

1. Naviguez jusqu'à la page Operators → Installed Operators.

2. Assurez-vous que Node Feature Discovery est listé dans le projet openshift-nfd avec un Status de InstallSucceeded.

   Note

   Pendant l'installation, un opérateur peut afficher un état Failed. Si l'installation réussit par la suite avec un message InstallSucceeded, vous pouvez ignorer le message Failed.

1. Naviguez jusqu'à la page Operators → Installed Operators et inspectez les onglets Operator Subscriptions et Install Plans pour voir s'il n'y a pas de défaillance ou d'erreur sous Status.
2. Naviguez vers la page Workloads → Pods et vérifiez les journaux pour les pods dans le projet openshift-nfd.

Procédure

1. Créez la ressource personnalisée (CR) NodeFeatureDiscovery suivante, puis enregistrez le fichier YAML dans le fichier NodeFeatureDiscovery.yaml:

   apiVersion: nfd.openshift.io/v1
   kind: NodeFeatureDiscovery
   metadata:
     name: nfd-instance
     namespace: openshift-nfd
   spec:
     instance: "" # instance is empty by default
     topologyupdater: false # False by default
     operand:
       image: registry.redhat.io/openshift4/ose-node-feature-discovery:v4.12
       imagePullPolicy: Always
     workerConfig:
       configData: |
         core:
         #  labelWhiteList:
         #  noPublish: false
           sleepInterval: 60s
         #  sources: [all]
         #  klog:
         #    addDirHeader: false
         #    alsologtostderr: false
         #    logBacktraceAt:
         #    logtostderr: true
         #    skipHeaders: false
         #    stderrthreshold: 2
         #    v: 0
         #    vmodule:
         ##   NOTE: the following options are not dynamically run-time configurable
         ##         and require a nfd-worker restart to take effect after being changed
         #    logDir:
         #    logFile:
         #    logFileMaxSize: 1800
         #    skipLogHeaders: false
         sources:
           cpu:
             cpuid:
         #     NOTE: whitelist has priority over blacklist
               attributeBlacklist:
                 - "BMI1"
                 - "BMI2"
                 - "CLMUL"
                 - "CMOV"
                 - "CX16"
                 - "ERMS"
                 - "F16C"
                 - "HTT"
                 - "LZCNT"
                 - "MMX"
                 - "MMXEXT"
                 - "NX"
                 - "POPCNT"
                 - "RDRAND"
                 - "RDSEED"
                 - "RDTSCP"
                 - "SGX"
                 - "SSE"
                 - "SSE2"
                 - "SSE3"
                 - "SSE4.1"
                 - "SSE4.2"
                 - "SSSE3"
               attributeWhitelist:
           kernel:
             kconfigFile: "/path/to/kconfig"
             configOpts:
               - "NO_HZ"
               - "X86"
               - "DMI"
           pci:
             deviceClassWhitelist:
               - "0200"
               - "03"
               - "12"
             deviceLabelFields:
               - "class"
     customConfig:
       configData: |
             - name: "more.kernel.features"
               matchOn:
               - loadedKMod: ["example_kmod3"]

1. Créez l'instance NodeFeatureDiscovery CR en exécutant la commande suivante :

   $ oc create -f NodeFeatureDiscovery.yaml

Procédure

1. Naviguez jusqu'à la page Operators → Installed Operators.
2. Trouvez Node Feature Discovery et voyez une boîte sous Provided APIs.
3. Cliquez sur Create instance.
4. Modifier les valeurs de NodeFeatureDiscovery CR.
5. Cliquez sur Create.

Procédure

1. Connectez-vous à la console web de OpenShift Container Platform.

2. Installez l'opérateur de gestion du module du noyau :

   1. Dans la console Web OpenShift Container Platform, cliquez sur Operators → OperatorHub.
   2. Sélectionnez Kernel Module Management Operator dans la liste des opérateurs disponibles, puis cliquez sur Install.
   3. Sur la page Install Operator, sélectionnez le site Installation mode comme A specific namespace on the cluster.
   4. Dans la liste Installed Namespace, sélectionnez l'espace de noms openshift-kmm.
   5. Cliquez sur Install.

1. Naviguez jusqu'à la page Operators → Installed Operators.

2. Assurez-vous que Kernel Module Management Operator est listé dans le projet openshift-kmm avec un Status de InstallSucceeded.

   Note

   Pendant l'installation, un opérateur peut afficher un état Failed. Si l'installation réussit par la suite avec un message InstallSucceeded, vous pouvez ignorer le message Failed.

Résolution de problèmes

1. Pour résoudre les problèmes liés à l'installation de l'opérateur :

   1. Naviguez jusqu'à la page Operators → Installed Operators et inspectez les onglets Operator Subscriptions et Install Plans pour voir s'il n'y a pas de défaillance ou d'erreur sous Status.
   2. Naviguez vers la page Workloads → Pods et vérifiez les journaux pour les pods dans le projet openshift-kmm.

Procédure

1. Installer KMM dans l'espace de noms openshift-kmm:

   1. Créez le fichier Namespace CR suivant et enregistrez le fichier YAML, par exemple, kmm-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-kmm

   2. Créez le fichier OperatorGroup CR suivant et enregistrez le fichier YAML, par exemple, kmm-op-group.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: kernel-module-management
        namespace: openshift-kmm

   3. Créez le fichier Subscription CR suivant et enregistrez le fichier YAML, par exemple, kmm-sub.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: kernel-module-management
        namespace: openshift-kmm
      spec:
        channel: release-1.0
        installPlanApproval: Automatic
        name: kernel-module-management
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        startingCSV: kernel-module-management.v1.0.0

   4. Créez l'objet d'abonnement en exécutant la commande suivante :

      $ oc create -f kmm-sub.yaml

Procédure

1. Installer KMM dans l'espace de noms openshift-kmm:

   1. Créez le CR Namespace suivant et enregistrez le fichier YAML, par exemple, le fichier kmm-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-kmm

   2. Créez l'objet SecurityContextConstraint suivant et enregistrez le fichier YAML, par exemple kmm-security-constraint.yaml:

      allowHostDirVolumePlugin: false
      allowHostIPC: false
      allowHostNetwork: false
      allowHostPID: false
      allowHostPorts: false
      allowPrivilegeEscalation: false
      allowPrivilegedContainer: false
      allowedCapabilities:
        - NET_BIND_SERVICE
      apiVersion: security.openshift.io/v1
      defaultAddCapabilities: null
      fsGroup:
        type: MustRunAs
      groups: []
      kind: SecurityContextConstraints
      metadata:
        name: restricted-v2
      priority: null
      readOnlyRootFilesystem: false
      requiredDropCapabilities:
        - ALL
      runAsUser:
        type: MustRunAsRange
      seLinuxContext:
        type: MustRunAs
      seccompProfiles:
        - runtime/default
      supplementalGroups:
        type: RunAsAny
      users: []
      volumes:
        - configMap
        - downwardAPI
        - emptyDir
        - persistentVolumeClaim
        - projected
        - secret

   3. Liez l'objet SecurityContextConstraint à l'objet ServiceAccount de l'opérateur en exécutant les commandes suivantes :

      $ oc apply -f kmm-security-constraint.yaml

      $ oc adm policy add-scc-to-user kmm-security-constraint -z kmm-operator-controller-manager -n openshift-kmm

   4. Créez le fichier OperatorGroup CR suivant et enregistrez le fichier YAML, par exemple, kmm-op-group.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: kernel-module-management
        namespace: openshift-kmm

   5. Créez le fichier Subscription CR suivant et enregistrez le fichier YAML, par exemple, kmm-sub.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: kernel-module-management
        namespace: openshift-kmm
      spec:
        channel: release-1.0
        installPlanApproval: Automatic
        name: kernel-module-management
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        startingCSV: kernel-module-management.v1.0.0

   6. Créez l'objet d'abonnement en exécutant la commande suivante :

      $ oc create -f kmm-sub.yaml

1. Liste de tous les nœuds correspondant à .spec.selector.
2. Construire un ensemble de toutes les versions du noyau fonctionnant sur ces nœuds.

3. Pour chaque version du noyau :

   1. Parcourez .spec.moduleLoader.container.kernelMappings et trouvez le nom de l'image de conteneur appropriée. Si le mappage du noyau est défini par build ou sign et que l'image du conteneur n'existe pas encore, exécutez la compilation, le travail de signature, ou les deux, selon les besoins.
   2. Créez un daemon de chargement de modules avec l'image du conteneur déterminée à l'étape précédente.
   3. Si .spec.devicePlugin est défini, créez un ensemble de démons d'extension de périphérique en utilisant la configuration spécifiée sous .spec.devicePlugin.container.

4. Lancer garbage-collect sur :

   1. Les ressources du jeu de démons existant ciblent les versions du noyau qui ne sont exécutées par aucun nœud de la grappe.
   2. Des emplois réussis dans le domaine de la construction.
   3. Des signatures réussies.

Procédure

1. Pour générer les fichiers modules.dep et .map pour une version spécifique du noyau, exécutez depmod -b /opt ${KERNEL_VERSION}.

1. Construire les modules du noyau.
2. Copiez les fichiers .ko dans une image plus petite destinée à l'utilisateur final, telle que ubi-minimal.

3. Pour tirer parti de DTK dans votre compilation en grappe, utilisez l'argument de compilation DTK_AUTO. La valeur est automatiquement définie par KMM lors de la création de la ressource Build. Voir l'exemple suivant.

   ARG DTK_AUTO
   FROM ${DTK_AUTO} as builder
   ARG KERNEL_VERSION
   WORKDIR /usr/src
   RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/kernel-module-management.git"]
   WORKDIR /usr/src/kernel-module-management/ci/kmm-kmod
   RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_VERSION}/build make all
   FROM registry.redhat.io/ubi8/ubi-minimal
   ARG KERNEL_VERSION
   RUN microdnf install kmod
   COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_VERSION}/
   COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_VERSION}/
   RUN depmod -b /opt ${KERNEL_VERSION}

Procédure

1. Vérifiez que le secret de la clé publique est correctement défini :

   $ oc get secret -o yaml <certificate secret name> | awk '/cert/{print $2; exit}' | base64 -d  | openssl x509 -inform der -text

   Le certificat devrait s'afficher avec un numéro de série, un émetteur, un sujet, etc.

2. Vérifiez que le secret de la clé privée est correctement défini :

   $ oc get secret -o yaml <clé privée nom secret> | awk '/key/{print $2 ; exit}' | base64 -d

   Cela devrait permettre d'afficher la clé contenue dans les lignes -----BEGIN PRIVATE KEY----- et -----END PRIVATE KEY-----.

Procédure

1. Utilisez l'opérateur Machine Config pour créer une ressource personnalisée (CR) MachineConfig qui contient le chemin d'accès /var/lib/firmware:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker 1
     name: 99-worker-kernel-args-firmware-path
   spec:
     kernelArguments:
       - 'firmware_class.path=/var/lib/firmware'

   1

   Vous pouvez configurer l'étiquette en fonction de vos besoins. Dans le cas d'OpenShift à nœud unique, utilisez les objets control-pane ou master.

2. En appliquant le CR MachineConfig, les nœuds sont automatiquement redémarrés.