流程

1. 使用 oc adm 命令提取与特定发行版本对应的 driver-toolkit 的镜像 URL：

   • 对于 x86 镜像，命令如下：

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

   • 对于 ARM 镜像，命令如下：

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

   输出示例

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

2. 使用有效的 pull secret 获取此镜像，如安装 OpenShift Container Platform 所需的 pull secret：

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

1. YAML 定义了 ImageStream，用于存储 simple-kmod 驱动程序容器镜像，以及用于构建容器的 BuildConfig。将此 YAML 保存为 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. 在以下命令中，使用您运行的 OpenShift Container Platform 版本的相关的正确 driver toolki 镜像替换 "DRIVER_TOOLKIT_IMAGE" 部分。

   $ 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. 使用创建镜像流和构建配置

   $ oc create -f 0000-buildconfig.yaml

4. 构建器 Pod 成功完成后，将驱动程序容器镜像部署为 DaemonSet。

   1. 驱动程序容器必须使用特权安全上下文运行，才能在主机上加载内核模块。以下 YAML 文件包含用于运行驱动程序容器的 RBAC 规则和 DaemonSet。将此 YAML 保存为 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. 创建 RBAC 规则和守护进程集：

      $ oc create -f 1000-drivercontainer.yaml

5. 当 pod 在 worker 节点上运行后，使用 lsmod 验证在主机机器上是否成功载入了 simple_kmod 内核模块。

   1. 验证 pod 是否正在运行：

      $ oc get pod -n simple-kmod-demo

      输出示例

      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. 在驱动程序容器 pod 中执行 lsmod 命令：

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

      输出示例

      simple_procfs_kmod     16384  0
      simple_kmod            16384  0

流程

1. 为 NFD Operator 创建命名空间。

   1. 创建定义 openshift-nfd 命名空间的以下 Namespace 自定义资源（CR），然后在 nfd-namespace.yaml 文件中保存 YAML：

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

   2. 运行以下命令创建命名空间：

      $ oc create -f nfd-namespace.yaml

2. 通过创建以下对象，在您上一步中创建的命名空间中安装 NFD Operator：

   1. 创建以下 OperatorGroup CR，并在 nfd -operatorgroup.yaml 文件中保存 YAML：

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

   2. 运行以下命令来创建 OperatorGroup CR:

      $ oc create -f nfd-operatorgroup.yaml

   3. 创建以下 Subscription CR，并将 YAML 保存到 nfd-sub.yaml 文件中：

      订阅示例

      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. 运行以下命令来创建订阅对象：

      $ oc create -f nfd-sub.yaml

   5. 进入 openshift-nfd 项目：

      $ oc project openshift-nfd

流程

1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
2. 从可用的 Operator 列表中选择 Node Feature Discovery，然后点 Install。
3. 在 Install Operator 页面中，选择 A specific namespace on the cluster，然后点 Install。您不需要创建命名空间，因为它已为您创建。

1. 进入到 Operators → Installed Operators 页面。

2. 确保 openshift-nfd 项目中列出了 Node Feature Discovery，Status 为 InstallSucceeded。

   注意

   在安装过程中，Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息，您可以忽略这个 Failed 信息。

1. 导航到 Operators → Installed Operators 页面，检查 Operator Subscriptions 和 Install Plans 选项卡中的 Status 项中是否有任何错误。
2. 导航到 Workloads → Pods 页面，在 openshift-nfd 项目中检查 pod 的日志。

流程

1. 创建以下 NodeFeatureDiscovery 自定义资源（CR），然后在 NodeFeatureDiscovery.yaml 文件中保存 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.15
       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. 运行以下命令来创建 NodeFeatureDiscovery CR 实例：

   $ oc create -f NodeFeatureDiscovery.yaml

流程

1. 进入到 Operators → Installed Operators 页面。
2. 查找 Node Feature Discovery，并在 Provided APIs 下看到一个方框。
3. 单击 Create instance。
4. 编辑 NodeFeatureDiscovery CR 的值。
5. 点 Create。

流程

1. 登陆到 OpenShift Container Platform Web 控制台。

2. 安装内核模块管理 Operator：

   1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
   2. 从可用的 Operator 列表中选择 Kernel Module Management Operator，然后点 Install。
   3. 在 Installed Namespace 列表中，选择 openshift-kmm 命名空间。
   4. 点 Install。

1. 进入到 Operators → Installed Operators 页面。

2. 确保 openshift-kmm 项目中列出的 Kernel Module Management Operator 的 Status 为 InstallSucceeded。

   注意

   在安装过程中，Operator 可能会显示 Failed 状态。如果安装过程结束后有 InstallSucceeded 信息，您可以忽略这个 Failed 信息。

故障排除

1. 排除安装 Operator 的问题：

   1. 导航到 Operators → Installed Operators 页面，检查 Operator Subscriptions 和 Install Plans 选项卡中的 Status 项中是否有任何错误。
   2. 进入到 Workloads → Pods 页面，在 openshift-kmm 项目中检查 pod 的日志。

流程

1. 在 openshift-kmm 命名空间中安装 KMM:

   1. 创建以下 Namespace CR 并保存 YAML 文件，如 kmm-namespace.yaml ：

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

   2. 创建以下 OperatorGroup CR 并保存 YAML 文件，如 kmm-op-group.yaml ：

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

   3. 创建以下 Subscription CR 并保存 YAML 文件，如 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. 运行以下命令来创建订阅对象：

      $ oc create -f kmm-sub.yaml

流程

1. 在 openshift-kmm 命名空间中安装 KMM:

   1. 创建以下 Namespace CR 并保存 YAML 文件，如 kmm-namespace.yaml 文件：

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

   2. 创建以下 SecurityContextConstraint 对象并保存 YAML 文件，如 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. 运行以下命令，将 SecurityContextConstraint 对象绑定到 Operator 的 ServiceAccount ：

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

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

   4. 创建以下 OperatorGroup CR 并保存 YAML 文件，如 kmm-op-group.yaml ：

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

   5. 创建以下 Subscription CR 并保存 YAML 文件，如 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. 运行以下命令来创建订阅对象：

      $ oc create -f kmm-sub.yaml

1. 列出与 .spec.selector 匹配的所有节点。
2. 构建在这些节点上运行的所有内核版本。

3. 对于每个内核版本：

   1. 进入 .spec.moduleLoader.container.kernelMappings，并找到适当的容器镜像名称。如果内核映射定义了 build 或 sign，且容器镜像尚不存在，请根据需要运行构建、签名 pod 或两者。
   2. 创建 worker pod 以拉取上一步中确定的容器镜像并运行 modprobe。
   3. 如果定义了 .spec.devicePlugin，请使用 .spec.devicePlugin.container 中指定的配置创建一个设备插件守护进程集。

4. 在以下运行 garbage-collect：

   1. 过时的设备插件 DaemonSet 不以任何节点为目标。
   2. 成功构建 pod。
   3. 成功签名 pod。

1. 构建内核模块。
2. 将 .ko 文件复制到较小的最终用户镜像中，如 ubi-minimal。

3. 要在集群内构建中使用 DTK，请使用 DTK_AUTO 构建参数。在创建 Build 资源时，该值由 KMM 自动设置。请参见以下示例。

   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/ubi9/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}

流程

1. 检查以确保正确设置公钥 secret：

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

   这应该会显示带有 Serial Number, Issuer, Subject 等的证书。

2. 检查以确保正确设置私钥 secret：

   $ oc get secret -o yaml <private key secret name> | awk '/key/{print $2; exit}' | base64 -d

   这应该显示包括在 -----BEGIN PRIVATE KEY----- 和 -----END PRIVATE KEY----- 行中的密钥。

流程

1. 将 MachineConfig 资源应用到现有的正在运行的集群。要识别需要更新的必要节点，您必须创建一个适当的 MachineConfigPool 资源。
2. MCO 通过节点应用重启节点。在任何重启的节点上，部署了两个新的 systemd 服务： pull 服务和 load 服务。
3. load 服务被配置为在 NetworkConfiguration 服务之前运行。该服务会尝试拉取预定义的内核模块镜像，然后使用该镜像卸载树内模块并加载 OOT 内核模块。
4. pull 服务配置为在 NetworkManager 服务后运行。该服务检查预配置的内核模块镜像是否位于节点的文件系统中。如果是，该服务正常存在，服务器将继续引导过程。如果没有，它会将镜像拉取到节点上，并在之后重启该节点。