Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

특화된 하드웨어 및 드라이버 활성화

OpenShift Container Platform 4.19

OpenShift Container Platform의 하드웨어 활성화 관련 정보

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform의 하드웨어 활성화에 대한 개요를 설명합니다.

1장. 특화된 하드웨어 및 드라이버 활성화 정보
링크 복사

Driver Toolkit (DTK)은 OpenShift Container Platform 페이로드의 컨테이너 이미지이며 드라이버 컨테이너를 빌드하는 데 기본 이미지로 사용됩니다. Driver Toolkit 이미지에는 커널 모듈을 빌드하거나 설치하는 데 일반적으로 필요한 커널 패키지와 드라이버 컨테이너에 필요한 몇 가지 도구가 포함되어 있습니다. 이러한 패키지의 버전은 해당 OpenShift Container Platform 릴리스의 RHCOS 노드에서 실행되는 커널 버전과 일치합니다.

드라이버 컨테이너는 Red Hat Enterprise Linux CoreOS(RHCOS)와 같은 컨테이너 운영 체제에서 트리 외부 커널 모듈과 드라이버를 빌드하고 배포하는 데 사용되는 컨테이너 이미지입니다. 커널 모듈과 드라이버는 운영 체제 커널에서 높은 수준의 권한으로 실행되는 소프트웨어 라이브러리입니다. 커널 기능을 확장하거나 새 장치를 제어하는 데 필요한 하드웨어별 코드를 제공합니다. 예를 들어 필드 프로그래밍 가능 게이트 어레이(FPGA) 또는 그래픽 처리 장치(GPU)와 같은 하드웨어 장치 및 모두 클라이언트 시스템에 커널 모듈이 필요한 소프트웨어 정의 스토리지 솔루션이 있습니다. 드라이버 컨테이너는 OpenShift Container Platform 배포에서 이러한 기술을 활성화하는 데 사용되는 소프트웨어 스택의 첫 번째 계층입니다.

2장. 드라이버 툴킷
링크 복사

Driver Toolkit과 OpenShift Container Platform 배포에서 특수 소프트웨어 및 하드웨어 장치를 활성화하기 위한 드라이버 컨테이너의 기본 이미지로 사용하는 방법에 대해 알아봅니다.

2.1. 드라이버 툴킷 정보
링크 복사

배경

Driver Toolkit은 드라이버 컨테이너를 빌드할 수 있는 기본 이미지로 사용되는 OpenShift Container Platform 페이로드의 컨테이너 이미지입니다. Driver Toolkit 이미지에는 커널 모듈을 빌드하거나 설치하는 데 일반적으로 필요한 커널 패키지와 드라이버 컨테이너에 필요한 몇 가지 도구가 포함되어 있습니다. 이러한 패키지의 버전은 해당 OpenShift Container Platform 릴리스의 Red Hat Enterprise Linux CoreOS(RHCOS) 노드에서 실행되는 커널 버전과 일치합니다.

드라이버 컨테이너는 RHCOS와 같은 컨테이너 운영 체제에서 트리 외부 커널 모듈 및 드라이버를 빌드하고 배포하는 데 사용되는 컨테이너 이미지입니다. 커널 모듈과 드라이버는 운영 체제 커널에서 높은 수준의 권한으로 실행되는 소프트웨어 라이브러리입니다. 커널 기능을 확장하거나 새 장치를 제어하는 데 필요한 하드웨어별 코드를 제공합니다. 예를 들어 Field Programmable Gate Arrays(예: Field Programmable Gate Arrays) 또는 GPU와 같은 하드웨어 장치, Lustre 병렬 파일 시스템과 같은 소프트웨어 정의 스토리지(SDS) 솔루션은 클라이언트 시스템에 커널 모듈이 필요합니다. 드라이버 컨테이너는 Kubernetes에서 이러한 기술을 활성화하는 데 사용되는 소프트웨어 스택의 첫 번째 계층입니다.

Driver Toolkit의 커널 패키지 목록에는 다음과 같은 종속성이 포함되어 있습니다.

  • kernel-core
  • kernel-devel
  • kernel-headers
  • kernel-modules
  • kernel-modules-extra

또한 Driver Toolkit에는 해당 실시간 커널 패키지도 포함되어 있습니다.

  • kernel-rt-core
  • kernel-rt-devel
  • kernel-rt-modules
  • kernel-rt-modules-extra

Driver Toolkit에는 다음을 포함하여 커널 모듈을 빌드하고 설치하는 데 일반적으로 필요한 몇 가지 도구가 있습니다.

  • elfutils-libelf-devel
  • kmod
  • binutilskabi-dw
  • kernel-abi-whitelists
  • 위의 종속 항목
목적

Driver Toolkit이 출시하기 전에는 사용자가 권한이 부여된 빌드를 사용하거나 호스트 machine-os-content 의 커널 RPM에서 설치하여 OpenShift Container Platform의 Pod 또는 빌드 구성에 커널 패키지를 설치합니다. Driver Toolkit은 인타이틀먼트 단계를 제거하여 프로세스를 간소화하고 Pod에서 machine-os-content에 액세스하는 권한 있는 작업을 피할 수 있습니다. Driver Toolkit은 사전 릴리스된 OpenShift Container Platform 버전에 액세스할 수 있는 파트너가 향후 OpenShift Container Platform 릴리스를 위한 하드웨어 장치용 드라이버 컨테이너를 사전 구축하는 데 사용할 수도 있습니다.

Driver Toolkit은 현재 OperatorHub에서 커뮤니티 Operator로 사용할 수 있는 KMM(커널 모듈 관리)에서도 사용됩니다. KMM은 외부 및 타사 커널 드라이버와 기본 운영 체제에 대한 지원 소프트웨어를 지원합니다. 사용자는 KMM의 모듈을 생성하여 드라이버 컨테이너를 빌드 및 배포할 수 있으며 장치 플러그인 또는 메트릭과 같은 지원 소프트웨어를 생성할 수 있습니다. 모듈에는 Driver Toolkit을 기반으로 드라이버 컨테이너를 빌드하는 빌드 구성이 포함될 수 있으며, KMM은 사전 빌드된 드라이버 컨테이너를 배포할 수 있습니다.

2.2. Driver Toolkit 컨테이너 이미지 가져오기
링크 복사

driver-toolkit 이미지는 Red Hat Ecosystem Catalog의 컨테이너 이미지 섹션과 OpenShift Container Platform 릴리스 페이로드에서 사용할 수 있습니다. OpenShift Container Platform의 최신 마이너 릴리스에 해당하는 이미지에는 카탈로그의 버전 번호로 태그가 지정됩니다. 특정 릴리스의 이미지 URL은 oc adm CLI 명령을 사용하여 찾을 수 있습니다.

2.2.1. registry.redhat.io에서 Driver Toolkit 컨테이너 이미지 가져오기
링크 복사

registry.redhat.io 에서 podman 또는 OpenShift Container Platform을 사용하여 driver-toolkit 이미지를 가져오는 방법은 Red Hat Ecosystem Catalog 에서 확인할 수 있습니다. 최신 마이너 릴리스용 드라이버 툴킷 이미지에는 registry.redhat.io 의 마이너 릴리스 버전이 태그로 지정되어 있습니다(예: registry.redhat.io/openshift4/driver-toolkit-rhel8:v4.19 ).

2.2.2. 페이로드에서 Driver Toolkit 이미지 URL 검색
링크 복사

사전 요구 사항

프로세스

  1. oc adm 명령을 사용하여 특정 릴리스에 해당하는 driver-toolkit 의 이미지 URL을 추출합니다.

    • x86 이미지의 경우 명령은 다음과 같습니다. 

      $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.19.z-x86_64 --image-for=driver-toolkit
      Copy to Clipboard Toggle word wrap

    • ARM 이미지의 경우 명령은 다음과 같습니다. 

      $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.19.z-aarch64 --image-for=driver-toolkit
      Copy to Clipboard Toggle word wrap

    출력 예

    quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:b53883ca2bac5925857148c4a1abc300ced96c222498e3bc134fe7ce3a1dd404
    Copy to Clipboard Toggle word wrap

  2. OpenShift Container Platform을 설치하는 데 필요한 풀 시크릿과 같은 유효한 풀 시크릿을 사용하여 이 이미지를 가져옵니다. 

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

2.3. Driver Toolkit 사용
링크 복사

예를 들어 Driver Toolkit은 simple-kmod 라는 매우 간단한 커널 모듈을 빌드하기 위한 기본 이미지로 사용할 수 있습니다.

참고

Driver Toolkit에는 커널 모듈에 서명하는 데 필요한 종속 항목인 openssl,mokutil 및 keyutils 가 포함되어 있습니다. 그러나 이 예에서는 simple-kmod 커널 모듈이 서명되지 않았으므로 Secure Boot 가 활성화된 시스템에 로드할 수 없습니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
  • Image Registry Operator 상태를 클러스터의 Managed로 설정합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 OpenShift CLI에 로그인했습니다.

프로세스

네임스페이스를 생성합니다. 예를 들면 다음과 같습니다. 

$ oc new-project simple-kmod-demo
Copy to Clipboard Toggle word wrap

  1. YAML은 simple-kmod 드라이버 컨테이너 이미지를 저장하기 위한 ImageStream과 컨테이너 빌드를 위한 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
    Copy to Clipboard Toggle word wrap

  2. "DRIVER_TOOLKIT_IMAGE" 대신 실행 중인 OpenShift Container Platform 버전에 대해 올바른 드라이버 툴킷 이미지를 다음 명령으로 대체하십시오. 

    $ OCP_VERSION=$(oc get clusterversion/version -ojsonpath={.status.desired.version})
    Copy to Clipboard Toggle word wrap 
    $ DRIVER_TOOLKIT_IMAGE=$(oc adm release info $OCP_VERSION --image-for=driver-toolkit)
    Copy to Clipboard Toggle word wrap 
    $ sed "s#DRIVER_TOOLKIT_IMAGE#${DRIVER_TOOLKIT_IMAGE}#" 0000-buildconfig.yaml.template > 0000-buildconfig.yaml
    Copy to Clipboard Toggle word wrap

  3. 이미지 스트림 및 빌드 구성을 만듭니다. 

    $ oc create -f 0000-buildconfig.yaml
    Copy to Clipboard Toggle word wrap

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

    2. RBAC 규칙 및 데몬 세트를 생성합니다. 

      $ oc create -f 1000-drivercontainer.yaml
      Copy to Clipboard Toggle word wrap

  5. 작업자 노드에서 pod가 실행된 후 lsmod가 있는 호스트 시스템에 simple_kmod 커널 모듈이 제대로 로드되었는지 확인합니다.

    1. pod가 실행 중인지 확인합니다. 

      $ oc get pod -n simple-kmod-demo
      Copy to Clipboard Toggle word wrap

      출력 예

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

    2. 드라이버 컨테이너 Pod에서 lsmod 명령을 실행합니다. 

      $ oc exec -it pod/simple-kmod-driver-container-p45cc -- lsmod | grep simple
      Copy to Clipboard Toggle word wrap

      출력 예

      simple_procfs_kmod     16384  0
simple_kmod            16384  0
      Copy to Clipboard Toggle word wrap

3장. Node Feature Discovery Operator
링크 복사

Node Feature Discovery (NFD) Operator 및 이를 사용하여 하드웨어 기능과 시스템 구성을 감지하기 위한 Kubernetes 애드온 기능인 NFD(Node Feature Discovery)을 오케스트레이션하여 노드 수준 정보를 공개하는 방법을 설명합니다.

NFD(Node Feature Discovery Operator)는 하드웨어 관련 정보로 노드에 레이블을 지정하여 OpenShift Container Platform 클러스터에서 하드웨어 기능 및 구성 검색을 관리합니다. NFD는 PCI 카드, 커널, 운영 체제 버전과 같은 노드별 속성을 사용하여 호스트에 레이블을 지정합니다.

NFD Operator는 "Node Feature Discovery"을 검색하여 Operator Hub에서 확인할 수 있습니다.

3.1. Node Feature Discovery Operator 설치
링크 복사

NFD(Node Feature Discovery) Operator는 NFD 데몬 세트를 실행하는 데 필요한 모든 리소스를 오케스트레이션합니다. 클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 NFD Operator를 설치할 수 있습니다.

3.1.1. CLI를 사용하여 NFD Operator 설치
링크 복사

클러스터 관리자는 CLI를 사용하여 NFD Operator를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. NFD Operator의 네임스페이스를 생성합니다.

    1. openshift-nfd 네임스페이스를 정의하는 다음 네임스페이스 사용자 정의 리소스(CR)를 만든 다음, YAML을 nfd-namespace.yaml 파일에 저장합니다. 클러스터 모니터링을 "true" 로 설정합니다. 

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nfd
  labels:
    name: openshift-nfd
    openshift.io/cluster-monitoring: "true"
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 네임스페이스를 생성합니다. 

      $ oc create -f nfd-namespace.yaml
      Copy to Clipboard Toggle word wrap

  2. 다음 오브젝트를 생성하여 이전 단계에서 생성한 네임스페이스에 NFD Operator를 설치합니다.

    1. 다음 OperatorGroup CR을 생성하고 해당 YAML을 nfd-operatorgroup.yaml 파일에 저장합니다. 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  generateName: openshift-nfd-
  name: openshift-nfd
  namespace: openshift-nfd
spec:
  targetNamespaces:
  - openshift-nfd
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다. 

      $ oc create -f nfd-operatorgroup.yaml
      Copy to Clipboard Toggle word wrap

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

    4. 다음 명령을 실행하여 서브스크립션 오브젝트를 생성합니다. 

      $ oc create -f nfd-sub.yaml
      Copy to Clipboard Toggle word wrap

    5. openshift-nfd 프로젝트로 변경합니다. 

      $ oc project openshift-nfd
      Copy to Clipboard Toggle word wrap

검증

  • Operator 배포가 완료되었는지 확인하려면 다음을 실행합니다. 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                      READY   STATUS    RESTARTS   AGE
nfd-controller-manager-7f86ccfb58-vgr4x   2/2     Running   0          10m
    Copy to Clipboard Toggle word wrap

    성공적인 배포에는 Running 상태가 표시됩니다.

3.1.2. 웹 콘솔을 사용하여 NFD Operator 설치
링크 복사

클러스터 관리자는 웹 콘솔을 사용하여 NFD Operator를 설치할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
  2. 사용 가능한 Operator 목록에서 Node Feature Discovery를 선택한 다음 설치를 클릭합니다.
  3. Operator 설치 페이지에서 클러스터의 특정 네임스페이스를 선택한 다음 설치를 클릭합니다. 네임스페이스가 생성되어 있으므로 생성할 필요가 없습니다.

검증

다음과 같이 NFD Operator가 설치되었는지 확인합니다.

  1. Operator → 설치된 Operator 페이지로 이동합니다.

  2. Node Feature Discovery가 openshift-nfd 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

    참고

    설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

문제 해결

Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.

  1. Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
  2. Workloads → Pod 페이지로 이동하여 openshift-nfd 프로젝트에서 Pod 로그를 확인합니다.

3.2. Node Feature Discovery Operator 사용
링크 복사

NFD( Node Feature Discovery ) Operator는 NodeFeatureDiscovery CR(사용자 정의 리소스)을 확인하여 Node-Feature-Discovery 데몬 세트를 실행하는 데 필요한 모든 리소스를 오케스트레이션합니다. NodeFeatureDiscovery CR을 기반으로 Operator는 선택한 네임스페이스에 피연산자(NFD) 구성 요소를 생성합니다. CR을 편집하여 다른 옵션 중에서 다른 네임스페이스, 이미지, 이미지 가져오기 정책 및 nfd-worker-conf 구성 맵을 사용할 수 있습니다.

클러스터 관리자는 OpenShift CLI(oc) 또는 웹 콘솔을 사용하여 NodeFeatureDiscovery CR을 생성할 수 있습니다.

참고

버전 4.12부터 NodeFeatureDiscovery CR의 operand.image 필드가 필수입니다. NFD Operator가 Operator Lifecycle Manager(OLM)를 사용하여 배포된 경우 OLM은 자동으로 operand.image 필드를 설정합니다. OpenShift Container Platform CLI 또는 OpenShift Container Platform 웹 콘솔을 사용하여 NodeFeatureDiscovery CR을 생성하는 경우 operand.image 필드를 명시적으로 설정해야 합니다.

3.2.1. CLI를 사용하여 NodeFeatureDiscovery CR 생성
링크 복사

클러스터 관리자는 OpenShift CLI(oc)를 사용하여 NodeFeatureDiscovery CR 인스턴스를 생성할 수 있습니다.

참고

spec.operand.image 설정에는 OpenShift Container Platform 릴리스 4.13 이상에서 사용할 -rhel9 이미지가 정의되어 있어야 합니다.

다음 예에서는 -rhel9 를 사용하여 올바른 이미지를 얻는 방법을 보여줍니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • NFD Operator를 설치했습니다.

프로세스

  1. NodeFeatureDiscovery CR을 생성합니다.

    NodeFeatureDiscovery CR의 예

    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-rhel9:v4.19
    1 
    
    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"]
    Copy to Clipboard Toggle word wrap

    1
    operand.image 필드는 필수입니다.

  2. 다음 명령을 실행하여 NodeFeatureDiscovery CR을 생성합니다. 

    $ oc apply -f <filename>
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 NodeFeatureDiscovery CR이 생성되었는지 확인합니다. 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                      READY   STATUS    RESTARTS   AGE
nfd-controller-manager-7f86ccfb58-vgr4x   2/2     Running   0          11m
nfd-master-hcn64                          1/1     Running   0          60s
nfd-master-lnnxx                          1/1     Running   0          60s
nfd-master-mp6hr                          1/1     Running   0          60s
nfd-worker-vgcz9                          1/1     Running   0          60s
nfd-worker-xqbws                          1/1     Running   0          60s
    Copy to Clipboard Toggle word wrap

    성공적인 배포에는 Running 상태가 표시됩니다.

3.2.2. 연결이 끊긴 환경에서 CLI를 사용하여 NodeFeatureDiscovery CR 생성
링크 복사

클러스터 관리자는 OpenShift CLI(oc)를 사용하여 NodeFeatureDiscovery CR 인스턴스를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • NFD Operator를 설치했습니다.
  • 필요한 이미지가 있는 미러 레지스트리에 액세스할 수 있습니다.
  • skopeo CLI 툴을 설치했습니다.

프로세스

  1. 레지스트리 이미지의 다이제스트를 확인합니다.

    1. 다음 명령을 실행합니다. 

      $ skopeo inspect docker://registry.redhat.io/openshift4/ose-node-feature-discovery:<openshift_version>
      Copy to Clipboard Toggle word wrap

      명령 예

      $ skopeo inspect docker://registry.redhat.io/openshift4/ose-node-feature-discovery:v4.12
      Copy to Clipboard Toggle word wrap

    2. 출력을 검사하여 이미지 다이제스트를 식별합니다.

      출력 예

      {
  ...
  "Digest": "sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
  ...
}
      Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 skopeo CLI 툴을 사용하여 registry.redhat.io 의 이미지를 미러 레지스트리로 복사합니다. 

    skopeo copy docker://registry.redhat.io/openshift4/ose-node-feature-discovery@<image_digest> docker://<mirror_registry>/openshift4/ose-node-feature-discovery@<image_digest>
    Copy to Clipboard Toggle word wrap

    명령 예

    skopeo copy docker://registry.redhat.io/openshift4/ose-node-feature-discovery@sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef docker://<your-mirror-registry>/openshift4/ose-node-feature-discovery@sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
    Copy to Clipboard Toggle word wrap

  3. NodeFeatureDiscovery CR을 생성합니다.

    NodeFeatureDiscovery CR의 예

    apiVersion: nfd.openshift.io/v1
kind: NodeFeatureDiscovery
metadata:
  name: nfd-instance
spec:
  operand:
    image: <mirror_registry>/openshift4/ose-node-feature-discovery@<image_digest>
    1 
    
    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"]
    Copy to Clipboard Toggle word wrap

    1
    operand.image 필드는 필수입니다.

  4. 다음 명령을 실행하여 NodeFeatureDiscovery CR을 생성합니다. 

    $ oc apply -f <filename>
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 NodeFeatureDiscovery CR의 상태를 확인합니다. 

    $ oc get nodefeaturediscovery nfd-instance -o yaml
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 ImagePullBackOff 오류 없이 포드가 실행 중인지 확인합니다. 

    $ oc get pods -n <nfd_namespace>
    Copy to Clipboard Toggle word wrap

3.2.3. 웹 콘솔을 사용하여 NodeFeatureDiscovery CR 생성
링크 복사

클러스터 관리자는 OpenShift Container Platform 웹 콘솔을 사용하여 NodeFeatureDiscovery CR을 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • NFD Operator를 설치했습니다.

프로세스

  1. Operator → 설치된 Operator 페이지로 이동합니다.
  2. Node Feature Discovery 섹션에서 제공된 API 에서 Create instance 를 클릭합니다.
  3. NodefeatureatureDiscovery CR의 값을 편집합니다.
  4. 생성을 클릭합니다.
참고

버전 4.12부터 NodeFeatureDiscovery CR의 operand.image 필드가 필수입니다. NFD Operator가 Operator Lifecycle Manager(OLM)를 사용하여 배포된 경우 OLM은 자동으로 operand.image 필드를 설정합니다. OpenShift Container Platform CLI 또는 OpenShift Container Platform 웹 콘솔을 사용하여 NodeFeatureDiscovery CR을 생성하는 경우 operand.image 필드를 명시적으로 설정해야 합니다.

3.3. Node Feature Discovery Operator 설정
링크 복사

3.3.1. 코어
링크 복사

core 섹션에는 특정 기능 소스와 관련이 없는 일반적인 구성 설정이 포함되어 있습니다.

core.sleepInterval

core.sleepInterval은 기능 검색 또는 재검색의 연속 통과 간격과 노드 레이블 재지정 간격을 지정합니다. 양수가 아닌 값은 무한 절전 상태를 의미합니다. 재검색되거나 레이블이 다시 지정되지 않습니다.

지정된 경우, 이 값은 더 이상 사용되지 않는 --sleep-interval 명령줄 플래그에 의해 무시됩니다.

사용 예

core:
  sleepInterval: 60s
1
Copy to Clipboard Toggle word wrap

기본값은 60s입니다.

core.sources

core.sources는 활성화된 기능 소스 목록을 지정합니다. 특수한 값 all은 모든 기능 소스를 활성화합니다.

지정된 경우, 더 이상 사용되지 않는 --sources 명령줄 플래그가 이 값을 대체합니다.

기본값: [all]

사용 예

core:
  sources:
    - system
    - custom
Copy to Clipboard Toggle word wrap

core.labelWhiteList

core.labelWhiteList는 레이블 이름을 기반으로 기능 레이블을 필터링하기 위한 정규식을 지정합니다. 일치하지 않는 레이블은 게시되지 않습니다.

정규 표현식은 레이블의 기반 이름 부분인 '/' 뒤에 있는 이름의 부분과만 일치합니다. 레이블 접두사 또는 네임스페이스가 생략됩니다.

지정된 경우, 더 이상 사용되지 않는 --label-whitelist 명령줄 플래그가 이 값을 대체합니다.

기본값: null

사용 예

core:
  labelWhiteList: '^cpu-cpuid'
Copy to Clipboard Toggle word wrap

core.noPublish

core.noPublish를 true로 설정하면 nfd-master와의 모든 통신이 비활성화됩니다. 이것은 실질적으로는 드라이런 플래그입니다. nfd-worker는 정상적으로 기능 감지를 실행하지만 레이블 요청은 nfd-master로 전송되지 않습니다.

--no-publish 명령줄 플래그가 지정된 경우 이 값은 해당 플래그보다 우선합니다.

예제:

사용 예

core:
  noPublish: true
1
Copy to Clipboard Toggle word wrap

기본값은 false입니다.

core.klog

다음 옵션은 대부분 런타임에 동적으로 조정할 수 있는 로거 구성을 지정합니다.

로거 옵션은 명령줄 플래그를 사용하여 지정할 수도 있으며, 해당 플래그는 해당 구성 파일 옵션보다 우선합니다.

core.klog.addDirHeader

true로 설정하면core.klog.addDirHeader에서 파일 디렉터리를 로그 메시지의 헤더에 추가합니다.

기본값: false

런타임 설정 가능: yes

core.klog.alsologtostderr

표준 오류 및 파일에 기록합니다.

기본값: false

런타임 설정 가능: yes

core.klog.logBacktraceAt

로깅이 file:N 행에 도달하면 스택 추적을 출력합니다.

기본값: empty

런타임 설정 가능: yes

core.klog.logDir

비어 있지 않은 경우 이 디렉터리에 로그 파일을 작성합니다.

기본값: empty

런타임 설정 가능: no

core.klog.logFile

비어 있지 않은 경우 이 로그 파일을 사용합니다.

기본값: empty

런타임 설정 가능: no

core.klog.logFileMaxSize

core.klog.logFileMaxSize는 로그 파일의 최대 크기를 정의합니다. 단위는 메가바이트입니다. 값이 0인 경우 최대 파일 크기는 무제한입니다.

기본값: 1800

런타임 설정 가능: no

core.klog.logtostderr

파일 대신 표준 오류에 기록합니다.

기본값: true

런타임 설정 가능: yes

core.klog.skipHeaders

core.klog.skipHeaders가 true로 설정된 경우 로그 메시지에서 헤더 접두사를 사용하지 않습니다.

기본값: false

런타임 설정 가능: yes

core.klog.skipLogHeaders

core.klog.skipLogHeaders가 true로 설정된 경우 로그 파일을 열 때 헤더를 사용하지 않습니다.

기본값: false

런타임 설정 가능: no

core.klog.stderrthreshold

임계값 이상의 로그는 stderr에 있습니다.

기본값: 2

런타임 설정 가능: yes

core.klog.v

core.klog.v는 로그 수준 세부 정보 표시의 수치입니다.

기본값: 0

런타임 설정 가능: yes

core.klog.vmodule

core.klog.vmodule은 파일 필터링된 로깅의 쉼표로 구분된 pattern=N 설정 목록입니다.

기본값: empty

런타임 설정 가능: yes

3.3.2. 소스
링크 복사

source 섹션에는 기능 소스 관련 구성 매개변수가 포함되어 있습니다.

sources.cpu.cpuid.attributeBlacklist

이 옵션에 나열된 cpuid 기능만을 공개합니다.

이 값은 sources.cpu.cpuid.attributeWhitelist로에 의해 재정의됩니다.

기본값: [BMI1, BMI2, CLMUL, CMOV, CX16, ERMS, F16C, HTT, LZCNT, MMX, MMXEXT, NX, POPCNT, RDRAND, RDSEED, RDTSCP, SGX, SGXLC, SSE, SSE2, SSE3, SSE4.1, SSE4.2, SSSE3]

사용 예

sources:
  cpu:
    cpuid:
      attributeBlacklist: [MMX, MMXEXT]
Copy to Clipboard Toggle word wrap

sources.cpu.cpuid.attributeWhitelist

이 옵션에 나열된 cpuid 기능만 게시합니다.

sources.cpu.cpuid.attributeWhitelist는 sources.cpu.cpuid.attributeBlacklist보다 우선합니다.

기본값: empty

사용 예

sources:
  cpu:
    cpuid:
      attributeWhitelist: [AVX512BW, AVX512CD, AVX512DQ, AVX512F, AVX512VL]
Copy to Clipboard Toggle word wrap

sources.kernel.kconfigFile

sources.kernel.kconfigFile은 커널 구성 파일의 경로입니다. 비어 있는 경우 NFD는 일반적인 표준 위치에서 검색을 실행합니다.

기본값: empty

사용 예

sources:
  kernel:
    kconfigFile: "/path/to/kconfig"
Copy to Clipboard Toggle word wrap

sources.kernel.configOpts

Source.kernel.configOpts는 기능 레이블로 게시하는 커널 구성 옵션을 나타냅니다.

기본값: [NO_HZ, NO_HZ_IDLE, NO_HZ_FULL, PREEMPT]

사용 예

sources:
  kernel:
    configOpts: [NO_HZ, X86, DMI]
Copy to Clipboard Toggle word wrap

sources.pci.deviceClassWhitelist

sources.pci.deviceClassWhitelist는 레이블을 게시할 PCI 장치 클래스 ID 목록입니다. 메인 클래스로만 (예: 03) 또는 전체 클래스-하위 클래스 조합(예: 0300)으로 지정할 수 있습니다. 전자는 모든 하위 클래스가 허용됨을 의미합니다. 레이블 형식은 deviceLabelFields를 사용하여 추가로 구성할 수 있습니다.

기본값: ["03", "0b40", "12"]

사용 예

sources:
  pci:
    deviceClassWhitelist: ["0200", "03"]
Copy to Clipboard Toggle word wrap

sources.pci.deviceLabelFields

sources.pci.deviceLabelFields 는 기능 레이블의 이름을 구성할 때 사용할 PCI ID 필드 세트입니다. 유효한 필드는 class,vendor,device,subsystem_vendor 및 subsystem_device입니다.

기본값: [class, vendor]

사용 예

sources:
  pci:
    deviceLabelFields: [class, vendor, device]
Copy to Clipboard Toggle word wrap

위의 설정 예제에서 NFD는 feature.node.kubernetes.io/pci-<class-id>_<vendor-id>_<device-id>.present=true와 같은 레이블을 게시합니다.

sources.usb.deviceClassWhitelist

sources.usb.deviceClassWhitelist 는 기능 레이블을 게시할 USB 장치 클래스 ID 목록입니다. 레이블 형식은 deviceLabelFields를 사용하여 추가로 구성할 수 있습니다.

기본값: ["0e", "ef", "fe", "ff"]

사용 예

sources:
  usb:
    deviceClassWhitelist: ["ef", "ff"]
Copy to Clipboard Toggle word wrap

sources.usb.deviceLabelFields

sources.usb.deviceLabelFields 는 기능 레이블의 이름을 작성할 USB ID 필드 세트입니다. 유효한 필드는 class,vendor, device입니다.

기본값: [class, vendor, device]

사용 예

sources:
  pci:
    deviceLabelFields: [class, vendor]
Copy to Clipboard Toggle word wrap

위의 config 예제에서 NFD는 feature.node.kubernetes.io/usb-<class-id>_<vendor-id>.present=true와 같은 레이블을 게시합니다.

sources.custom

sources.custom 은 사용자별 레이블을 생성하기 위해 사용자 정의 기능 소스에서 처리하는 규칙 목록입니다.

기본값: empty

사용 예

source:
  custom:
  - name: "my.custom.feature"
    matchOn:
    - loadedKMod: ["e1000e"]
    - pciId:
        class: ["0200"]
        vendor: ["8086"]
Copy to Clipboard Toggle word wrap

3.4. NodeFeatureRule 사용자 정의 리소스에 관하여
링크 복사

NodeFeatureRule 객체는 노드의 규칙 기반 사용자 정의 레이블을 위해 설계된 NodeFeatureDiscovery 사용자 정의 리소스입니다. 일부 사용 사례에는 하드웨어 공급업체가 장치에 대한 특정 레이블을 생성하기 위해 애플리케이션별 레이블을 지정하거나 배포하는 것이 포함됩니다.

NodeFeatureRule 객체는 공급업체 또는 애플리케이션별 레이블과 오염을 생성하는 메서드를 제공합니다. 유연한 규칙 기반 메커니즘을 사용하여 레이블 및 노드 기능을 기반으로 하는 테인트를 생성합니다.

3.5. NodeFeatureRule 사용자 정의 리소스 사용
링크 복사

규칙 세트가 조건에 맞는 경우 노드에 레이블을 지정하기 위해 NodeFeatureRule 객체를 생성합니다.

프로세스

  1. 다음 텍스트를 포함하는 nodefeaturerule.yaml 이라는 사용자 지정 리소스 파일을 만듭니다. 

    apiVersion: nfd.openshift.io/v1
kind: NodeFeatureRule
metadata:
  name: example-rule
spec:
  rules:
    - name: "example rule"
      labels:
        "example-custom-feature": "true"
      # Label is created if all of the rules below match
      matchFeatures:
        # Match if "veth" kernel module is loaded
        - feature: kernel.loadedmodule
          matchExpressions:
            veth: {op: Exists}
        # Match if any PCI device with vendor 8086 exists in the system
        - feature: pci.device
          matchExpressions:
            vendor: {op: In, value: ["8086"]}
    Copy to Clipboard Toggle word wrap

    이 사용자 정의 리소스는 veth 모듈이 로드되고 공급업체 코드 8086이 있는 PCI 장치가 클러스터에 있을 때 레이블이 지정됨을 지정합니다.

  2. 다음 명령을 실행하여 nodefeaturerule.yaml 파일을 클러스터에 적용합니다. 

    $ oc apply -f https://raw.githubusercontent.com/kubernetes-sigs/node-feature-discovery/v0.13.6/examples/nodefeaturerule.yaml
    Copy to Clipboard Toggle word wrap

    이 예제에서는 veth 모듈이 로드된 노드에 기능 레이블을 적용하고 공급업체 코드가 8086 인 모든 PCI 장치가 존재합니다.

    참고

    최대 1분의 재라벨링 지연이 발생할 수 있습니다.

3.6. NFD 토폴로지 업데이트 프로그램 사용
링크 복사

NFD(Node Feature Discovery) Topology Updater는 작업자 노드에서 할당된 리소스를 검사하는 데몬입니다. 이 노드는 영역별로 새 Pod에 할당할 수 있는 리소스를 차지하며, 여기서 영역이 NUMA(Non-Uniform Memory Access) 노드일 수 있습니다. NFD Topology Updater는 클러스터의 모든 작업자 노드에 해당하는 NodeResourceTopology CR(사용자 정의 리소스)을 생성하는 nfd-master에 정보를 전달합니다. NFD Topology Updater의 한 인스턴스는 클러스터의 각 노드에서 실행됩니다.

NFD에서 토폴로지 업데이트 프로그램 작업자를 활성화하려면 Node Feature Discovery Operator 사용 섹션에 설명된 대로 NodeFeatureDiscovery CR에서 topologyupdater 변수를 true 로 설정합니다.

3.6.1. NodeResourceTopology CR
링크 복사

NFD Topology Updater를 사용하여 실행하는 경우 NFD는 다음과 같은 노드 리소스 하드웨어 토폴로지에 해당하는 사용자 정의 리소스 인스턴스를 생성합니다. 

apiVersion: topology.node.k8s.io/v1alpha1
kind: NodeResourceTopology
metadata:
  name: node1
topologyPolicies: ["SingleNUMANodeContainerLevel"]
zones:
  - name: node-0
    type: Node
    resources:
      - name: cpu
        capacity: 20
        allocatable: 16
        available: 10
      - name: vendor/nic1
        capacity: 3
        allocatable: 3
        available: 3
  - name: node-1
    type: Node
    resources:
      - name: cpu
        capacity: 30
        allocatable: 30
        available: 15
      - name: vendor/nic2
        capacity: 6
        allocatable: 6
        available: 6
  - name: node-2
    type: Node
    resources:
      - name: cpu
        capacity: 30
        allocatable: 30
        available: 15
      - name: vendor/nic1
        capacity: 3
        allocatable: 3
        available: 3
Copy to Clipboard Toggle word wrap

3.6.2. NFD 토폴로지 업데이터 명령줄 플래그
링크 복사

사용 가능한 명령줄 플래그를 보려면 nfd-topology-updater -help 명령을 실행하세요. 예를 들어 podman 컨테이너에서 다음 명령을 실행합니다. 

$ podman run gcr.io/k8s-staging-nfd/node-feature-discovery:master nfd-topology-updater -help
Copy to Clipboard Toggle word wrap
-ca-파일

-ca-file 플래그는 NFD Topology Updater에서 상호 TLS 인증을 제어하는 -cert-file 및 '-key-file'flags와 함께 세 가지 플래그 중 하나입니다. 이 플래그는 nfd-master의 신뢰성을 확인하는 데 사용되는 TLS 루트 인증서를 지정합니다.

기본값: empty

중요

-ca-file 플래그는 -cert-file 및 -key-file 플래그와 함께 지정해야 합니다.

예제

$ nfd-topology-updater -ca-file=/opt/nfd/ca.crt -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key
Copy to Clipboard Toggle word wrap

-cert-file

-cert-file 플래그는 NFD Topology Updater에서 상호 TLS 인증을 제어하는 -ca-file 및 -key-file flags 와 함께 세 가지 플래그 중 하나입니다. 이 플래그는 발신 요청을 인증하기 위해 제공되는 TLS 인증서를 지정합니다.

기본값: empty

중요

-cert-file 플래그는 -ca-file 및 -key-file 플래그와 함께 지정해야 합니다.

예제

$ nfd-topology-updater -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key -ca-file=/opt/nfd/ca.crt
Copy to Clipboard Toggle word wrap

-h, -help

사용량을 출력하고 종료합니다.

-key-file

-key-file 플래그는 NFD Topology Updater의 상호 TLS 인증을 제어하는 -ca-file 및 -cert-file 플래그와 함께 세 가지 플래그 중 하나입니다. 이 플래그는 발신 요청을 인증하는 데 사용되는 지정된 인증서 파일 또는 -cert-file 에 해당하는 개인 키를 지정합니다.

기본값: empty

중요

-key-file 플래그는 -ca-file 및 -cert-file 플래그와 함께 지정해야 합니다.

예제

$ nfd-topology-updater -key-file=/opt/nfd/updater.key -cert-file=/opt/nfd/updater.crt -ca-file=/opt/nfd/ca.crt
Copy to Clipboard Toggle word wrap

-kubelet-config-file

-kubelet-config-file 은 Kubelet의 설정 파일의 경로를 지정합니다.

기본값: /host-var/lib/kubelet/config.yaml

예제

$ nfd-topology-updater -kubelet-config-file=/var/lib/kubelet/config.yaml
Copy to Clipboard Toggle word wrap

-no-publish

no-publish 플래그는 nfd-master와의 모든 통신을 비활성화하여 nfd-topology-updater에 대한 예행 실행 플래그로 설정합니다. NFD Topology Updater는 일반적으로 리소스 하드웨어 토폴로지 탐지를 실행하지만 CR 요청이 nfd-master로 전송되지 않습니다.

기본값: false

예제

$ nfd-topology-updater -no-publish
Copy to Clipboard Toggle word wrap

3.6.2.1. -oneshot
링크 복사

-oneshot 플래그를 사용하면 리소스 하드웨어 토폴로지 탐지에서 한 번 통과한 후 NFD Topology Updater가 종료됩니다.

기본값: false

예제

$ nfd-topology-updater -oneshot -no-publish
Copy to Clipboard Toggle word wrap

-podresources-socket

-podresources-socket 플래그는 kubelet이 사용 중인 CPU 및 장치를 검색하고 해당 CPU 및 장치를 검색할 수 있도록 gRPC 서비스를 내보내는 Unix 소켓의 경로를 지정합니다.

기본값: /host-var/liblib/kubelet/pod-resources/kubelet.sock

예제

$ nfd-topology-updater -podresources-socket=/var/lib/kubelet/pod-resources/kubelet.sock
Copy to Clipboard Toggle word wrap

-server

-server 플래그는 연결할 nfd-master 끝점의 주소를 지정합니다.

기본값: localhost:8080

예제

$ nfd-topology-updater -server=nfd-master.nfd.svc.cluster.local:443
Copy to Clipboard Toggle word wrap

-server-name-override

-server-name-override 플래그는 nfd-master TLS 인증서에서 예상되는 CN(일반 이름)을 지정합니다. 이 플래그는 주로 개발 및 디버깅 목적으로 사용됩니다.

기본값: empty

예제

$ nfd-topology-updater -server-name-override=localhost
Copy to Clipboard Toggle word wrap

-sleep-interval

-sleep-interval 플래그는 리소스 하드웨어 토폴로지 재검정 및 사용자 정의 리소스 업데이트 사이의 간격을 지정합니다. 양수가 아닌 값은 무한 절전 간격을 의미하고 재검색되지 않습니다.

기본값: 60s

예제

$ nfd-topology-updater -sleep-interval=1h
Copy to Clipboard Toggle word wrap

-version

버전을 출력하고 종료합니다.

-watch-namespace

-watch-namespace 플래그는 지정된 네임스페이스에서 실행 중인 Pod에서만 리소스 하드웨어 토폴로지 검사를 수행하도록 네임스페이스를 지정합니다. 지정된 네임스페이스에서 실행되지 않는 Pod는 리소스 계정 중에 고려되지 않습니다. 이는 테스트 및 디버깅 목적에 특히 유용합니다. * 값은 모든 네임스페이스의 모든 Pod가 회계 프로세스 중 고려됨을 의미합니다.

기본값: *

예제

$ nfd-topology-updater -watch-namespace=rte
Copy to Clipboard Toggle word wrap

4장. 커널 모듈 관리 Operator
링크 복사

Kernel Module Management (KMM) Operator와 OpenShift Container Platform 클러스터에 트리 외부 커널 모듈 및 장치 플러그인을 배포하는 데 사용할 수 있는 방법을 설명합니다.

4.1. 커널 모듈 관리 Operator 정보
링크 복사

KMM(커널 모듈 관리) Operator는 OpenShift Container Platform 클러스터에 트리 외부 커널 모듈 및 장치 플러그인을 관리, 빌드, 서명 및 배포합니다.

KMM은 트리 외부 커널 Module 및 관련 장치 플러그인을 설명하는 새 모듈 CRD를 추가합니다. Module 리소스를 사용하여 모듈을 로드하는 방법을 구성하고, 커널 버전에 대한 ModuleLoader 이미지를 정의하고, 특정 커널 버전에 대한 모듈을 빌드하고 서명하기 위한 지침을 포함할 수 있습니다.

KMM은 모든 커널 모듈에 대해 한 번에 여러 커널 버전을 수용할 수 있도록 설계되어 노드를 원활하게 업그레이드하고 애플리케이션 다운타임을 줄일 수 있습니다.

4.2. Kernel Module Management Operator 설치
링크 복사

클러스터 관리자는 OpenShift CLI 또는 웹 콘솔을 사용하여 KMM(커널 모듈 관리) Operator를 설치할 수 있습니다.

KMM Operator는 OpenShift Container Platform 4.12 이상에서 지원됩니다. 버전 4.11에 KMM을 설치하려면 특정 추가 단계가 필요하지 않습니다. 버전 4.10 및 이전 버전에 KMM을 설치하는 방법에 대한 자세한 내용은 "이전 버전의 OpenShift Container Platform에 Kernel Module Management Operator 설치" 섹션을 참조하십시오.

4.2.1. 웹 콘솔을 사용하여 Kernel Module Management Operator 설치
링크 복사

클러스터 관리자는 OpenShift Container Platform 웹 콘솔을 사용하여 KMM(커널 모듈 관리) Operator를 설치할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.

  2. Kernel Module Management Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 Kernel Module Management Operator 를 선택한 다음 설치를 클릭합니다.
    3. Installed Namespace 목록에서 openshift-kmm 네임스페이스를 선택합니다.
    4. 설치를 클릭합니다.

검증

KMM Operator가 설치되었는지 확인하려면 다음을 수행하십시오.

  1. Operator → 설치된 Operator 페이지로 이동합니다.

  2. Kernel Module Management Operator 가 openshift-kmm 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

    참고

    설치하는 동안 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

문제 해결

  1. Operator 설치 문제를 해결하려면 다음을 수행합니다.

    1. Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
    2. 워크로드 → Pod 페이지로 이동하여 openshift-kmm 프로젝트에서 Pod 로그를 확인합니다.

4.2.2. CLI를 사용하여 Kernel Module Management Operator 설치
링크 복사

클러스터 관리자는 OpenShift CLI를 사용하여 KMM(커널 모듈 관리) Operator를 설치할 수 있습니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 OpenShift CLI에 로그인했습니다.

프로세스

  1. openshift-kmm 네임스페이스에 KMM을 설치합니다.

    1. 다음 Namespace CR을 생성하고 YAML 파일을 저장합니다(예: kmm-namespace.yaml ). 

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-kmm
      Copy to Clipboard Toggle word wrap

    2. 다음 OperatorGroup CR을 생성하고 YAML 파일을 저장합니다(예: kmm-op-group.yaml ). 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: kernel-module-management
  namespace: openshift-kmm
      Copy to Clipboard Toggle word wrap

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

    4. 다음 명령을 실행하여 서브스크립션 오브젝트를 생성합니다. 

      $ oc create -f kmm-sub.yaml
      Copy to Clipboard Toggle word wrap

검증

  • Operator 배포가 완료되었는지 확인하려면 다음 명령을 실행합니다. 

    $ oc get -n openshift-kmm deployments.apps kmm-operator-controller
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                              READY UP-TO-DATE  AVAILABLE AGE
kmm-operator-controller           1/1   1           1         97s
    Copy to Clipboard Toggle word wrap

    Operator를 사용할 수 있습니다.

KMM Operator는 OpenShift Container Platform 4.12 이상에서 지원됩니다. 버전 4.10 및 이전 버전의 경우 새 SecurityContextConstraint 오브젝트를 생성하여 Operator의 ServiceAccount 에 바인딩해야 합니다. 클러스터 관리자는 OpenShift CLI를 사용하여 KMM(커널 모듈 관리) Operator를 설치할 수 있습니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 OpenShift CLI에 로그인했습니다.

프로세스

  1. openshift-kmm 네임스페이스에 KMM을 설치합니다.

    1. 다음 Namespace CR을 생성하고 YAML 파일을 저장합니다(예: kmm-namespace.yaml ). 

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-kmm
      Copy to Clipboard Toggle word wrap

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

    3. 다음 명령을 실행하여 SecurityContextConstraint 오브젝트를 Operator의 ServiceAccount 에 바인딩합니다. 

      $ oc apply -f kmm-security-constraint.yaml
      Copy to Clipboard Toggle word wrap 
      $ oc adm policy add-scc-to-user kmm-security-constraint -z kmm-operator-controller -n openshift-kmm
      Copy to Clipboard Toggle word wrap

    4. 다음 OperatorGroup CR을 생성하고 YAML 파일을 저장합니다(예: kmm-op-group.yaml ). 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: kernel-module-management
  namespace: openshift-kmm
      Copy to Clipboard Toggle word wrap

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

    6. 다음 명령을 실행하여 서브스크립션 오브젝트를 생성합니다. 

      $ oc create -f kmm-sub.yaml
      Copy to Clipboard Toggle word wrap

검증

  • Operator 배포가 완료되었는지 확인하려면 다음 명령을 실행합니다. 

    $ oc get -n openshift-kmm deployments.apps kmm-operator-controller
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                              READY UP-TO-DATE  AVAILABLE AGE
kmm-operator-controller           1/1   1           1         97s
    Copy to Clipboard Toggle word wrap

    Operator를 사용할 수 있습니다.

4.3. 커널 모듈 관리 연산자 구성
링크 복사

대부분의 경우, 커널 모듈 관리(KMM) 운영자의 기본 구성은 수정할 필요가 없습니다. 하지만 사용자의 환경에 맞게 운영자 설정을 수정할 수 있습니다.

프로세스

  • 설정을 수정하려면 Operator 네임스페이스에 kmm-operator-manager-config 라는 이름의 ConfigMap을 만들고 관련 데이터를 입력한 후 다음 명령을 사용하여 컨트롤러를 다시 시작합니다. 

    $ oc rollout restart -n "$namespace" deployment/kmm-operator-controller
    Copy to Clipboard Toggle word wrap

    $namespace 의 값은 설치 방법에 따라 달라집니다.

    출력 예

    apiVersion: v1
data:
  controller_config.yaml: |
    worker:
      firmwareHostPath: /example/different/firmware/path
kind: ConfigMap
metadata:
  name: kmm-operator-manager-config
  namespace: openshift-kmm
    Copy to Clipboard Toggle word wrap

참고

KMM 허브를 구성하려면 KMM 허브 컨트롤러의 네임스페이스에 kmm-operator-hub-manager-config라는 이름을 사용하여 ConfigMap을 만듭니다.

Expand
표 4.1. 운영자 구성 매개변수
매개변수설명

healthProbeBindAddress

운영자가 kubelet 상태 프로브를 모니터링하는 주소를 정의합니다. 권장되는 값은 :8081 입니다.

job.gcDelay

성공적인 빌드 포드가 삭제되기 전에 보존되어야 하는 기간을 정의합니다. 이 설정에 유효한 값에 대한 자세한 내용은 ParseDuration을 참조하세요. 기본값은 0s 입니다.

leaderElection.enabled

KMM 운영자의 복제본이 항상 하나만 실행되도록 리더 선거를 사용할지 여부를 결정합니다. 자세한 내용은 임대를 참조하세요. 기본값은 true입니다.

leaderElection.resourceID

리더 선택에서 리더 잠금을 유지하는 데 사용하는 리소스의 이름을 결정합니다. KMM의 기본값은 kmm.sigs.x-k8s.io 입니다. KMM-hub의 기본값은 kmm-hub.sigs.x-k8s.io 입니다.

metrics.bindAddress

지표 서버의 바인딩 주소를 결정합니다. 메트릭 서버를 비활성화하려면 이 값을 "0"으로 설정합니다. 기본값은 169.254.169.0/29 입니다.

metrics.disableHTTP2

true 인 경우 지표 서버의 HTTP/2를 CVE-2023-44487 의 완화 조치로 비활성화합니다. 기본값은 true입니다.

metrics.enableAuthnAuthz

kube-apiserver와 함께 SubjectAccessReviews 를 사용하여 TokenReviews 를 사용하여 메트릭이 인증되었는지 여부를 확인합니다.

인증 및 권한 부여의 경우 컨트롤러에 다음 규칙이 있는 ClusterRole 이 필요합니다.

  • apiGroups: authentication.k8s.io, resources: tokenreviews, verbs: create
  • apiGroups: authorization.k8s.io, resources: subjectaccessreviews, verbs: create

예를 들어 Prometheus를 사용하여 메트릭을 스크랩하려면 클라이언트에 다음 규칙이 있는 ClusterRole 이 필요합니다.

  • nonResourceURLs: "/metrics", verbs: get

기본값은 true입니다.

metrics.secureServing

HTTP 대신 HTTPS를 통해 메트릭이 제공되는지 여부를 결정합니다. 기본값은 true입니다.

webhook.disableHTTP2

true 인 경우 CVE-2023-44487 에 대한 완화 조치로 웹훅 서버에 대한 HTTP/2가 비활성화됩니다. 기본값은 true입니다.

webhook.port

운영자가 웹훅 요청을 모니터링하는 포트를 정의합니다. 기본값은 9443 입니다.

worker.runAsUser

작업자 컨테이너 보안 컨텍스트의 runAsUser 필드 값을 결정합니다. 자세한 내용은 SecurityContext를 참조하세요. 기본값은 9443 입니다.

worker.seLinuxType

작업자 컨테이너의 보안 컨텍스트의 seLinuxOptions.type 필드의 값을 결정합니다. 자세한 내용은 SecurityContext를 참조하세요. 기본값은 spc_t 입니다.

worker.firmwareHostPath

설정된 경우, 이 필드의 값은 작업자 컨테이너에 의해 노드의 /sys/module/firmware_class/parameters/path 파일에 기록됩니다. 자세한 내용은 커널의 펌웨어 검색 경로 설정을 참조하세요. 기본값은 /var/lib/firmware 입니다.

4.3.1. 커널 모듈 언로드
링크 복사

새로운 버전으로 이동하거나 노드에 바람직하지 않은 부작용이 발생하는 경우 커널 모듈을 언로드해야 합니다.

프로세스

  • KMM으로 로드된 모듈을 노드에서 언로드하려면 해당 모듈 리소스를 삭제합니다. 그런 다음 KMM은 필요한 경우 작업자 포드를 생성하여 modprobe -r을 실행하고 노드에서 커널 모듈을 언로드합니다.

    주의

    작업자 Pod를 언로드할 때 KMM에는 커널 모듈을 로드할 때 사용하는 모든 리소스가 필요합니다. 여기에는 모듈에서 참조되는 ServiceAccount 와 권한이 있는 KMM 작업자 Pod를 실행하기 위해 정의된 RBAC가 포함됩니다. 여기에는 .spec.imageRepoSecret 에 참조된 모든 풀 비밀도 포함됩니다.

    KMM이 노드에서 커널 모듈을 언로드할 수 없는 상황을 방지하려면 모듈 리소스가 종료 중을 포함하여 어떤 상태에서든 클러스터에 여전히 존재하는 동안 해당 리소스가 삭제되지 않도록 해야 합니다. KMM에는 최소한 하나 의 모듈 리소스가 포함된 네임스페이스의 삭제를 거부하는 유효성 검사 승인 웹훅이 포함되어 있습니다.

4.3.2. 커널 펌웨어 검색 경로 설정
링크 복사

Linux 커널은 펌웨어 검색 경로 에서 설명한 대로 firmware_class.path 매개변수를 펌웨어 검색 경로로 허용합니다.

KMM 워커 포드는 kmod를 로드하기 전에 sysfs에 기록하여 노드에서 이 값을 설정할 수 있습니다.

프로세스

  • 펌웨어 검색 경로를 정의하려면 Operator 구성에서 worker.setFirmwareClassPath를 /var/lib/firmware 로 설정합니다.

4.4. 커널 모듈 관리 운영자 제거
링크 복사

KMM Operator가 설치된 방법에 따라 다음 절차 중 하나를 사용하여 KMM Operator를 제거합니다.

4.4.1. Red Hat 카탈로그 설치 제거
링크 복사

Red Hat 카탈로그에서 KMM을 설치한 경우 이 절차를 사용하세요.

프로세스

다음 방법을 사용하여 KMM Operator를 제거하세요.

  • OpenShift 콘솔의 Operators -> Installed Operators 에서 Operator를 찾아 제거합니다.
참고

또는 KMM 네임스페이스에서 구독 리소스를 삭제할 수 있습니다.

4.4.2. CLI 설치 제거
링크 복사

OpenShift CLI를 사용하여 KMM Operator를 설치한 경우 이 명령을 사용합니다.

프로세스

  • 다음 명령을 실행하여 KMM Operator를 제거합니다. 

    $ oc delete -k https://github.com/rh-ecosystem-edge/kernel-module-management/config/default
    Copy to Clipboard Toggle word wrap
    참고

    이 명령을 사용하면 모듈 CRD와 클러스터의 모든 모듈 인스턴스가 삭제됩니다.

4.5. 커널 모듈 배포
링크 복사

커널 모듈 관리(KMM)는 클러스터의 노드 및 모듈 리소스를 모니터링하여 커널 모듈을 노드에 로드하거나 언로드해야 하는지 여부를 결정합니다.

모듈을 사용하려면 노드에 다음이 포함되어야 합니다.

  • 모듈의 .spec.selector 필드와 일치하는 레이블입니다.
  • 모듈의 .spec.moduleLoader.container.kernelMappings 필드에 있는 항목 중 하나와 일치하는 커널 버전입니다.
  • 모듈에 정렬된 업그레이드( ordered_upgrade.md )가 구성된 경우 .spec.moduleLoader.container.version 필드와 일치하는 레이블이 필요합니다.

KMM이 모듈 리소스에 구성된 대로 노드를 원하는 상태로 조정하면 대상 노드에 작업자 포드를 만들어 필요한 작업을 실행합니다. KMM 운영자는 포드의 결과를 모니터링하고 정보를 기록합니다. 운영자는 모듈이 성공적으로 로드되면 이 정보를 사용하여 노드 객체에 레이블을 지정하고, 구성된 경우 장치 플러그인을 실행합니다.

워커 포드는 다음 작업을 수행하는 KMM 워커 바이너리를 실행합니다.

  • 모듈 리소스에 구성된 kmod 이미지를 가져옵니다. Kmod 이미지는 .ko 파일을 포함하는 표준 OCI 이미지입니다.
  • 포드의 파일 시스템에서 이미지를 추출합니다.
  • 지정된 인수로 modprobe를 실행하여 필요한 작업을 수행합니다.

4.5.1. 모듈 사용자 정의 리소스 정의
링크 복사

모듈 사용자 정의 리소스 정의(CRD)는 kmod 이미지를 통해 클러스터의 모든 노드 또는 선택한 노드에 로드할 수 있는 커널 모듈을 나타냅니다. Module CR(사용자 정의 리소스)은 호환되는 하나 이상의 커널 버전과 노드 선택기를 지정합니다.

Module 리소스에 호환되는 버전은 .spec.moduleLoader.container.kernelMappings 아래에 나열됩니다. 커널 매핑은 literal 버전과 일치하거나 regexp 를 사용하여 여러 항목을 동시에 일치시킬 수 있습니다.

Module 리소스의 조정 루프는 다음 단계를 실행합니다.

  1. .spec.selector 와 일치하는 모든 노드를 나열합니다.
  2. 해당 노드에서 실행 중인 모든 커널 버전 세트를 빌드합니다.

  3. 각 커널 버전에 대해 다음을 수행합니다.

    1. .spec.moduleLoader.container.kernelMappings 를 통과하여 적절한 컨테이너 이미지 이름을 찾습니다. 커널 매핑에 빌드 또는 서명이 정의되어 있고 컨테이너 이미지가 아직 없는 경우 필요에 따라 빌드, 서명 포드 또는 둘 다를 실행합니다.
    2. 이전 단계에서 결정된 컨테이너 이미지를 가져오기 위해 워커 포드를 만들고 modprobe를 실행합니다.
    3. .spec.devicePlugin 이 정의된 경우 .spec.devicePlugin.container 에 지정된 구성을 사용하여 장치 플러그인 데몬 세트를 생성합니다.

  4. 다음과 같이 garbage-collect 을 실행합니다.

    1. 어떤 노드도 타겟으로 삼지 않는 오래된 장치 플러그인 DaemonSets입니다 .
    2. 성공적인 빌드 포드.
    3. 성공적인 서명 포드.

4.5.2. 커널 모듈 간에 소프트 종속 항목 설정
링크 복사

일부 구성에서는 모듈이 기호를 통해 서로 직접 의존하지 않아도 제대로 작동하려면 여러 커널 모듈을 특정 순서로 로드해야 합니다. 이를 소프트 종속 항목이라고 합니다. depmod 는 일반적으로 이러한 종속성을 인식하지 못하며 생성하는 파일에 표시되지 않습니다. 예를 들어 mod_a 에 mod_b 에 대한 소프트 종속성이 있는 경우modprobe mod_a 는 mod_b 를 로드하지 않습니다.

modulesLoadingOrder 필드를 사용하여 모듈 사용자 정의 리소스 정의(CRD)에서 소프트 종속성을 선언하면 이러한 상황을 해결할 수 있습니다. 

# ...
spec:
  moduleLoader:
    container:
      modprobe:
        moduleName: mod_a
        dirName: /opt
        firmwarePath: /firmware
        parameters:
          - param=1
        modulesLoadingOrder:
          - mod_a
          - mod_b
Copy to Clipboard Toggle word wrap

위의 구성에서 워커 포드는 kmod 이미지에서 mod_a를 로드하기 전에 먼저 트리 내 mod_b를 언로드하려고 시도합니다. 워커 포드가 종료되고 mod_a 가 언로드되면 mod_b는 다시 로드되지 않습니다.

참고

마지막으로 로드할 목록의 첫 번째 값은 moduleName 과 같아야 합니다.

4.6. 보안 및 권한
링크 복사

중요

커널 모듈을 로드하는 것은 매우 민감한 작업입니다. 커널 모듈이 로드되면 노드에서 모든 종류의 작업을 수행할 수 있는 모든 권한이 제공됩니다.

4.6.1. ServiceAccounts 및 SecurityContextConstraints
링크 복사

KMM(커널 모듈 관리)은 노드에 커널 모듈을 로드하는 권한 있는 워크로드를 생성합니다. 해당 워크로드에는 privileged SCC( SecurityContextConstraint ) 리소스를 사용할 수 있는 ServiceAccounts 가 필요합니다.

해당 워크로드에 대한 권한 부여 모델은 Module 리소스의 네임스페이스와 해당 사양에 따라 다릅니다.

  • .spec.moduleLoader.serviceAccountName 또는 .spec.devicePlugin.serviceAccountName 필드가 설정된 경우 항상 사용됩니다.

  • 해당 필드가 설정되지 않은 경우 다음을 수행합니다.

    • 모듈 리소스가 Operator의 네임스페이스(기본적으로 openshift-kmm )에 생성되면 KMM은 기본적인 강력한 ServiceAccounts를 사용하여 작업자 및 장치 플러그인 포드를 실행합니다.
    • 모듈 리소스가 다른 네임스페이스에 생성되면 KMM은 네임스페이스의 기본 ServiceAccount를 사용하여 포드를 실행합니다. 권한 있는 SCC를 사용하도록 수동으로 활성화하지 않는 한 Module 리소스는 privileged 워크로드를 실행할 수 없습니다.
중요

OpenShift-kmm 는 신뢰할 수 있는 네임스페이스입니다.

RBAC 권한을 설정할 때 openshift-kmm 네임스페이스에서 Module 리소스를 생성하는 사용자 또는 ServiceAccount 가 있으면 KMM이 클러스터의 모든 노드에서 권한이 있는 워크로드를 자동으로 실행합니다.

모든 ServiceAccount가 권한이 있는 SCC를 사용하고 작업자 또는 장치 플러그인 포드를 실행하도록 허용하려면 다음 예와 같이 oc adm policy 명령을 사용할 수 있습니다. 

$ oc adm policy add-scc-to-user privileged -z "${serviceAccountName}" [ -n "${namespace}" ]
Copy to Clipboard Toggle word wrap

4.6.2. Pod 보안 표준
링크 복사

OpenShift는 사용 중인 보안 컨텍스트에 따라 네임스페이스 Pod 보안 수준을 자동으로 설정하는 동기화 메커니즘을 실행합니다. 아무 작업도 필요하지 않습니다.

4.7. in-tree 모듈을 out-of-tree 모듈로 교체
링크 복사

KMM(커널 모듈 관리)을 사용하여 필요에 따라 커널에 로드하거나 언로드할 수 있는 커널 모듈을 빌드할 수 있습니다. 이러한 모듈은 시스템을 재부팅할 필요 없이 커널의 기능을 확장합니다. 모듈은 기본 제공 또는 동적으로 로드됨으로 구성할 수 있습니다.

동적으로 로드된 모듈에는 in-tree 모듈 및 OOT(out-of-tree) 모듈이 포함됩니다. in-tree 모듈은 Linux 커널 트리 내부에 있습니다. 즉, 이미 커널에 포함되어 있습니다. out-of-tree 모듈은 Linux 커널 트리 외부에 있습니다. 일반적으로 트리에 제공된 커널 모듈의 새 버전을 테스트하거나 비호환성을 처리하는 등 개발 및 테스트 목적으로 작성됩니다.

KMM에서 로드한 일부 모듈은 노드에 이미 로드된 트리 내 모듈을 대체할 수 있습니다. 모듈을 로드하기 전에 트리 내 모듈을 언로드하려면 .spec.moduleLoader.container.inTreeModulesToRemove 필드의 값을 언로드하려는 모듈로 설정합니다. 다음 예제는 모든 커널 매핑에 대한 모듈 교체를 보여줍니다. 

# ...
spec:
  moduleLoader:
    container:
      modprobe:
        moduleName: mod_a

      inTreeModulesToRemove: [mod_a, mod_b]
Copy to Clipboard Toggle word wrap

이 예에서 moduleLoader pod는 inTreeModulesToRemove를 사용하여 moduleLoader 이미지에서 mod_a를 로드하기 전에 트리 내 mod_a 및 mod_b를 언로드합니다. moduleLoader`pod is terminated and `mod_a가 언로드되면 mod_b가 다시 로드되지 않습니다.

다음은 특정 커널 매핑의 모듈 교체를 위한 예입니다. 

# ...
spec:
  moduleLoader:
    container:
      kernelMappings:
        - literal: 6.0.15-300.fc37.x86_64
          containerImage: "some.registry/org/my-kmod:${KERNEL_FULL_VERSION}"
          inTreeModulesToRemove: [<module_name>, <module_name>]
Copy to Clipboard Toggle word wrap

4.7.1. 모듈 CR의 예
링크 복사

다음은 주석 처리 Module 예제입니다. 

apiVersion: kmm.sigs.x-k8s.io/v1beta1
kind: Module
metadata:
  name: <my_kmod>
spec:
  moduleLoader:
    container:
      modprobe:
        moduleName: <my_kmod>
1 

        dirName: /opt
2 

        firmwarePath: /firmware
3 

        parameters:
4 

          - param=1
      kernelMappings:
5 

        - literal: 6.0.15-300.fc37.x86_64
          containerImage: some.registry/org/my-kmod:6.0.15-300.fc37.x86_64
        - regexp: '^.+\fc37\.x86_64$'
6 

          containerImage: "some.other.registry/org/<my_kmod>:${KERNEL_FULL_VERSION}"
        - regexp: '^.+$'
7 

          containerImage: "some.registry/org/<my_kmod>:${KERNEL_FULL_VERSION}"
8 

          build:
            buildArgs:
9 

              - name: ARG_NAME
                value: <some_value>
            secrets:
              - name: <some_kubernetes_secret>
10 

            baseImageRegistryTLS:
11 

              insecure: false
              insecureSkipTLSVerify: false
12 

            dockerfileConfigMap:
13 

              name: <my_kmod_dockerfile>
          sign:
            certSecret:
              name: <cert_secret>
14 

            keySecret:
              name: <key_secret>
15 

            filesToSign:
              - /opt/lib/modules/${KERNEL_FULL_VERSION}/<my_kmod>.ko
          registryTLS:
16 

            insecure: false
17 

            insecureSkipTLSVerify: false
    serviceAccountName: <sa_module_loader>
18 

  devicePlugin:
19 

    container:
      image: some.registry/org/device-plugin:latest
20 

      env:
        - name: MY_DEVICE_PLUGIN_ENV_VAR
          value: SOME_VALUE
      volumeMounts:
21 

        - mountPath: /some/mountPath
          name: <device_plugin_volume>
    volumes:
22 

      - name: <device_plugin_volume>
        configMap:
          name: <some_configmap>
    serviceAccountName: <sa_device_plugin>
23 

  imageRepoSecret:
24 

    name: <secret_name>
  selector:
    node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap
1 1 1
필수 항목입니다.
2
선택 사항입니다.
3
선택 사항: 이 경로의 내용을 kmm-operator-manager-config 구성 맵의 worker.setFirmwareClassPath (기본 설정은 /var/lib/firmware )에 지정된 경로로 복사합니다. 이 동작은 커널 모듈을 삽입하기 위해 modprobe가 호출되기 전에 발생합니다.
4
선택 사항입니다.
5
하나 이상의 커널 항목이 필요합니다.
6
정규 표현식과 일치하는 커널을 실행하는 각 노드에 대해 KMM은 태그나 다이제스트를 포함했는지 확인합니다. 컨테이너 이미지에 태그나 다이제스트를 지정하지 않으면 검증 웹훅이 오류를 반환하고 모듈을 적용하지 않습니다.
7
다른 커널의 경우 my-kmod ConfigMap의 Dockerfile을 사용하여 이미지를 빌드합니다.
8
고객의 kmod를 보관하는 컨테이너 이미지입니다. 이 컨테이너에는 cp 바이너리가 포함되어야 합니다.
9
선택 사항입니다.
10
선택 사항: some-kubernetes-secret 의 값은 /run/secrets/some-kubernetes-secret 의 빌드 환경에서 가져올 수 있습니다.
11
이 필드에는 아무런 효과가 없습니다. kmod 이미지를 빌드하거나 kmod 이미지 내에서 kmod에 서명할 때, 신뢰할 수 없는 인증 기관(CA)에서 서명한 인증서를 제공하는 레지스트리에서 기본 이미지를 가져와야 할 때가 있습니다. KMM이 해당 CA를 신뢰하려면 클러스터의 CA 번들을 대체하여 새 CA도 신뢰해야 합니다.

클러스터의 CA 번들을 교체하는 방법을 알아보려면 "추가 리소스"를 참조하세요.

12
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면, 빌드는 일반 HTTP를 사용하여 Dockerfile FROM 명령어에서 이미지를 가져올 때 TLS 서버 인증서 유효성 검사를 건너뜁니다.
13
필수 항목입니다.
14
필수: 'cert' 키가 있는 공용 secureboot 키를 보유한 시크릿입니다.
15
필수: 키가 'key'인 개인 secureboot 키를 보유한 시크릿입니다.
16
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 KMM은 일반 HTTP를 사용하여 컨테이너 이미지가 이미 존재하는지 확인할 수 있습니다.
17
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 KMM은 컨테이너 이미지가 이미 존재하는지 확인할 때 TLS 서버 인증서 유효성 검사를 건너뜁니다.
18
선택 사항입니다.
19
선택 사항:
20
필수: 장치 플러그인 섹션이 있는 경우
21
선택 사항:
22
선택 사항:
23
선택 사항:
24
선택 사항: 모듈 로더 및 장치 플러그인 이미지를 가져오는 데 사용됩니다.

4.8. 장치 플러그인과 함께 트리 내 모듈 사용
링크 복사

어떤 경우에는 트리 외부 커널 모듈을 로드하지 않고 대신 트리 내부 모듈을 사용하고 장치 플러그인만 실행하도록 KMM 모듈을 구성해야 할 수도 있습니다. 이러한 경우 다음 예제와 같이 모듈 사용자 정의 리소스(CR)에서 moduleLoader 매개변수를 생략하고 devicePlugin 섹션만 남겨둘 수 있습니다.

예제 모듈 CR

apiVersion: kmm.sigs.x-k8s.io/v1beta1
kind: Module
metadata:
  name: my-kmod
spec:
  selector:
    node-role.kubernetes.io/worker: ""
  devicePlugin:
    container:
      image: some.registry/org/my-device-plugin:latest
Copy to Clipboard Toggle word wrap

4.10. kmod 이미지 생성
링크 복사

KMM(커널 모듈 관리)은 .ko 파일을 포함하는 표준 OCI 이미지인 특수 목적의 kmod 이미지와 함께 작동합니다. .ko 파일의 위치는 다음 패턴과 일치해야 합니다: <prefix>/lib/modules/[kernel-version]/ .

.ko 파일을 사용할 때 다음 사항을 염두에 두십시오.

  • 대부분의 경우 <prefix>는 /opt 와 같아야 합니다. 이는 모듈 CRD의 기본값입니다.
  • kernel-version은 비어 있을 수 없으며 커널 모듈이 빌드된 커널 버전과 동일해야 합니다.

.ko 파일 외에도 kmod 이미지에는 cp 바이너리도 있어야 합니다. .ko 파일은 이 이미지에서 Operator가 생성한 이미지 로더 워커 포드로 복사되기 때문입니다. 이는 최소 요구 사항이며 이미지에 다른 바이너리 도구가 필요하지 않습니다.

4.10.1. depmod 실행
링크 복사

빌드 프로세스가 끝날 때 depmod를 실행하여 modules.dep 및 .map 파일을 생성하는 것이 좋습니다. 이 기능은 kmod 이미지에 여러 개의 커널 모듈이 포함되어 있고, 모듈 중 하나가 다른 모듈에 종속되어 있는 경우에 특히 유용합니다.

참고

kernel-devel 패키지를 다운로드하려면 Red Hat 서브스크립션이 있어야 합니다.

프로세스

  • 다음 명령을 실행하여 특정 커널 버전에 대한 modules.dep 및 .map 파일을 생성합니다. 

    $ depmod -b /opt ${KERNEL_FULL_VERSION}+`.
    Copy to Clipboard Toggle word wrap
4.10.1.1. Dockerfile 예
링크 복사

OpenShift Container Platform에서 이미지를 빌드하는 경우 Driver Tool Kit (DTK) 사용을 고려하십시오.

자세한 내용은 권한이 부여된 빌드 사용을 참조하십시오. 

apiVersion: v1
kind: ConfigMap
metadata:
  name: kmm-ci-dockerfile
data:
  dockerfile: |
    ARG DTK_AUTO
    FROM ${DTK_AUTO} as builder
    ARG KERNEL_FULL_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_FULL_VERSION}/build make all
    FROM registry.redhat.io/ubi9/ubi-minimal
    ARG KERNEL_FULL_VERSION
    RUN microdnf install kmod
    COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/
    COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/
    RUN depmod -b /opt ${KERNEL_FULL_VERSION}
Copy to Clipboard Toggle word wrap

4.10.2. 클러스터의 빌드
링크 복사

KMM은 클러스터에 kmod 이미지를 빌드할 수 있습니다. 다음 지침을 따르십시오.

  • 커널 매핑의 build 섹션을 사용하여 빌드 지침을 제공합니다.
  • 컨테이너 이미지의 Dockerfile을 dockerfile 키 아래의 ConfigMap 리소스에 복사합니다.
  • ConfigMap 이 Module 과 동일한 네임스페이스에 있는지 확인합니다.

KMM은 containerImage 필드에 지정된 이미지 이름이 있는지 확인합니다. 이 경우 빌드를 건너뜁니다.

그러지 않으면 KMM에서 Build 리소스를 생성하여 이미지를 빌드합니다. 이미지가 빌드된 후 KMM은 Module 조정을 진행합니다. 다음 예제를 참조하십시오. 

# ...
- regexp: '^.+$'
  containerImage: "some.registry/org/<my_kmod>:${KERNEL_FULL_VERSION}"
  build:
    buildArgs:
1 

      - name: ARG_NAME
        value: <some_value>
    secrets:
2 

      - name: <some_kubernetes_secret>
3 

    baseImageRegistryTLS:
      insecure: false
4 

      insecureSkipTLSVerify: false
5 

    dockerfileConfigMap:
6 

      name: <my_kmod_dockerfile>
  registryTLS:
    insecure: false
7 

    insecureSkipTLSVerify: false
8
Copy to Clipboard Toggle word wrap
1
선택 사항:
2
선택 사항:
3
/run/secrets/some-kubernetes-secret 으로 빌드 Pod에 마운트됩니다.
4
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 빌드가 일반 HTTP를 사용하여 Dockerfile FROM 명령에서 이미지를 가져올 수 있습니다.
5
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 빌드에서 일반 HTTP를 사용하여 Dockerfile FROM 명령에서 이미지를 가져올 때 모든 TLS 서버 인증서 검증을 건너뜁니다.
6
필수 항목입니다.
7
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 KMM이 일반 HTTP를 사용하여 컨테이너 이미지가 이미 존재하는지 확인할 수 있습니다.
8
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 KMM은 컨테이너 이미지가 이미 존재하는지 확인할 때 모든 TLS 서버 인증서 검증을 건너뜁니다.

job.gcDelay 매개변수가 Operator 구성에 설정되어 있지 않은 한, 빌드가 성공하면 해당 빌드 포드는 즉시 가비지 수집됩니다. 실패한 빌드 포드는 항상 보존되며, 빌드를 다시 시작하려면 관리자가 수동으로 삭제해야 합니다.

4.10.3. Driver Toolkit 사용
링크 복사

Driver Toolkit(DTK)은 빌드 kmod 로더 이미지를 빌드하기 위한 편리한 기본 이미지입니다. 여기에는 현재 클러스터에서 실행 중인 OpenShift 버전의 툴과 라이브러리가 포함되어 있습니다.

프로세스

여러 단계로 구성된 Dockerfile의 첫 번째 단계로 DTK를 사용합니다.

  1. 커널 모듈을 빌드합니다.
  2. .ko 파일을 ubi-minimal 과 같은 작은 최종 사용자 이미지에 복사합니다.

  3. 클러스터 내 빌드에서 DTK를 활용하려면 DTK_AUTO 빌드 인수를 사용합니다. 이 값은 Build 리소스를 생성할 때 KMM에 의해 자동으로 설정됩니다. 다음 예제를 참조하십시오. 

    ARG DTK_AUTO
FROM ${DTK_AUTO} as builder
ARG KERNEL_FULL_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_FULL_VERSION}/build make all
FROM ubi9/ubi-minimal
ARG KERNEL_FULL_VERSION
RUN microdnf install kmod
COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/
COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/
RUN depmod -b /opt ${KERNEL_FULL_VERSION}
    Copy to Clipboard Toggle word wrap

4.11. 커널 모듈 관리(KMM)에서 서명 사용
링크 복사

Secure Boot가 활성화된 시스템에서 모든 커널 모듈(kmods)은 MOK(Machine Owner's Key) 데이터베이스에 등록된 공개/개인 키 쌍으로 서명해야 합니다. 배포판의 일부로 배포된 드라이버는 이미 배포의 개인 키로 서명해야 하지만 커널 모듈 빌드의 경우 KMM은 커널 매핑의 sign 섹션을 사용하여 커널 모듈 서명을 지원합니다.

Secure Boot 사용에 대한 자세한 내용은 공개 및 개인 키 쌍생성을 참조하십시오.

사전 요구 사항

  • 올바른 (DER) 형식의 공개 개인 키 쌍입니다.
  • MOK 데이터베이스에 등록된 공개 키가 있는 하나 이상의 보안 부팅 가능 노드.
  • 미리 빌드된 드라이버 컨테이너 이미지이거나, 클러스터 내에서 빌드하는 데 필요한 소스 코드와 Dockerfile입니다.

4.12. secureboot를 위한 키 추가
링크 복사

KMM(KMM)을 사용하여 커널 모듈에 서명하려면 인증서와 개인 키가 필요합니다. 이러한 키 생성 방법에 대한 자세한 내용은 공개 및 개인 키 쌍 생성을 참조하십시오.

공개 키 및 개인 키 쌍을 추출하는 방법에 대한 자세한 내용은 개인 키로 커널 모듈 서명을 참조하십시오. 1~4단계를 사용하여 파일로 키를 추출합니다.

프로세스

  1. 인증서가 포함된 sb_cert.cer 파일과 개인 키가 포함된 sb_cert.priv 파일을 만듭니다. 

    $ openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 -batch -config configuration_file.config -outform DER -out my_signing_key_pub.der -keyout my_signing_key.priv
    Copy to Clipboard Toggle word wrap

  2. 다음 방법 중 하나를 사용하여 파일을 추가합니다.

    • 파일을 시크릿 으로 직접 추가합니다. 

      $ oc create secret generic my-signing-key --from-file=key=<my_signing_key.priv>
      Copy to Clipboard Toggle word wrap 
      $ oc create secret generic my-signing-key-pub --from-file=cert=<my_signing_key_pub.der>
      Copy to Clipboard Toggle word wrap

    • 파일을 base64로 인코딩하여 추가합니다. 

      $ cat sb_cert.priv | base64 -w 0 > my_signing_key2.base64
      Copy to Clipboard Toggle word wrap 
      $ cat sb_cert.cer | base64 -w 0 > my_signing_key_pub.base64
      Copy to Clipboard Toggle word wrap

  3. 인코딩된 텍스트를 YAML 파일에 추가합니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: my-signing-key-pub
  namespace: default
    1 
    
type: Opaque
data:
  cert: <base64_encoded_secureboot_public_key>

---
apiVersion: v1
kind: Secret
metadata:
  name: my-signing-key
  namespace: default
    2 
    
type: Opaque
data:
  key: <base64_encoded_secureboot_private_key>
    Copy to Clipboard Toggle word wrap
    1 2
    namespace - default 를 유효한 네임스페이스로 바꿉니다.

  4. YAML 파일을 적용합니다. 

    $ oc apply -f <yaml_filename>
    Copy to Clipboard Toggle word wrap

4.12.1. 키 확인
링크 복사

키를 추가한 후에는 키가 올바르게 설정되었는지 확인해야 합니다.

프로세스

  1. 공개 키 시크릿이 올바르게 설정되었는지 확인합니다. 

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

    Serial Number, Issuer, Subject 등의 인증서가 표시되어야 합니다.

  2. 개인 키 보안이 올바르게 설정되었는지 확인합니다. 

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

    -----BEGIN PRIVATE KEY----- 및 -----END PRIVATE KEY----- 줄에 묶은 키가 표시되어야 합니다.

4.13. 미리 빌드된 이미지에서 kmod 서명
링크 복사

하드웨어 벤더에 의해 배포되거나 다른 위치에서 빌드된 이미지와 같이 사전 빌드된 이미지가 있는 경우 이 절차를 사용하십시오.

다음 YAML 파일은 공개/개인 키 쌍에 필요한 키 이름(개인 키의 key, 공개 키의 cert)이 있는 시크릿으로 공개/개인 키 쌍을 추가합니다. 그러면 클러스터에서 unsignedImage 이미지를 가져와서 열고, filesToSign 에 나열된 커널 모듈에 서명하고, 다시 추가하고, 결과 이미지를 containerImage 로 푸시합니다.

그런 다음 KMM은 선택기와 일치하는 모든 노드에 서명된 kmods를 로드합니다. 공개 키가 MOK 데이터베이스에 있는 모든 노드와 서명을 무시하는 보안 부팅이 활성화되지 않은 모든 노드에 kmod가 성공적으로 로드됩니다.

사전 요구 사항

  • keySecret 및 certSecret 비밀은 나머지 리소스와 동일한 네임스페이스에 생성되었습니다.

프로세스

  • YAML 파일을 적용합니다. 

    ---
apiVersion: kmm.sigs.x-k8s.io/v1beta1
kind: Module
metadata:
  name: example-module
spec:
  moduleLoader:
    serviceAccountName: default
    container:
      modprobe:
    1 
    
        moduleName: '<module_name>'
      kernelMappings:
        # the kmods will be deployed on all nodes in the cluster with a kernel that matches the regexp
        - regexp: '^.*\.x86_64$'
          # the container to produce containing the signed kmods
          containerImage: <image_name>
    2 
    
          sign:
            # the image containing the unsigned kmods (we need this because we are not building the kmods within the cluster)
            unsignedImage: <image_name>
    3 
    
            keySecret: # a secret holding the private secureboot key with the key 'key'
              name: <private_key_secret_name>
            certSecret: # a secret holding the public secureboot key with the key 'cert'
              name: <certificate_secret_name>
            filesToSign: # full path within the unsignedImage container to the kmod(s) to sign
              - /opt/lib/modules/4.18.0-348.2.1.el8_5.x86_64/kmm_ci_a.ko
  imageRepoSecret:
    # the name of a secret containing credentials to pull unsignedImage and push containerImage to the registry
    name: repo-pull-secret
  selector:
    kubernetes.io/arch: amd64
    Copy to Clipboard Toggle word wrap
1
로드할 kmod의 이름입니다.
2
컨테이너 이미지의 이름입니다. 예를 들어, quay.io/myuser/my-driver:<kernelversion .
3
서명이 없는 이미지의 이름입니다. 예를 들어, quay.io/myuser/my-driver:<kernelversion .

4.14. kmod 이미지 빌드 및 서명
링크 복사

소스 코드가 있고 이미지를 먼저 빌드해야 하는 경우 이 절차를 사용하십시오.

다음 YAML 파일은 리포지토리의 소스 코드를 사용하여 새 컨테이너 이미지를 빌드합니다. 생성된 이미지는 임시 이름으로 레지스트리에 다시 저장되며 이 임시 이미지는 sign 섹션의 매개변수를 사용하여 서명됩니다.

임시 이미지 이름은 최종 이미지 이름을 기반으로 하며 < containerImage>:<tag>-<namespace>_<module name>_kmm_unsigned 로 설정됩니다.

예를 들어, 다음 YAML 파일을 사용하면 커널 모듈 관리(KMM)는 서명되지 않은 kmods를 포함하는 example.org/repository/minimal-driver:final-default_example-module_kmm_unsigned 라는 이름의 이미지를 빌드하고 레지스트리에 푸시합니다. 그런 다음 서명된 kmods가 포함된 example.org/repository/minimal-driver:final 이라는 두 번째 이미지를 생성합니다. 워커 포드가 끌어오는 것은 이 두 번째 이미지이며, 클러스터 노드에 로드될 kmods를 담고 있습니다.

서명이 완료되면 레지스트리에서 임시 이미지를 안전하게 삭제할 수 있습니다. 필요한 경우 다시 빌드됩니다.

사전 요구 사항

  • keySecret 및 certSecret 비밀은 나머지 리소스와 동일한 네임스페이스에 생성되었습니다.

프로세스

  • YAML 파일을 적용합니다. 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-module-dockerfile
  namespace: <namespace>
    1 
    
data:
  dockerfile: |
    ARG DTK_AUTO
    ARG KERNEL_VERSION
    FROM ${DTK_AUTO} as builder
    WORKDIR /build/
    RUN git clone -b main --single-branch https://github.com/rh-ecosystem-edge/kernel-module-management.git
    WORKDIR kernel-module-management/ci/kmm-kmod/
    RUN make
    FROM registry.access.redhat.com/ubi9/ubi:latest
    ARG KERNEL_VERSION
    RUN yum -y install kmod && yum clean all
    RUN mkdir -p /opt/lib/modules/${KERNEL_VERSION}
    COPY --from=builder /build/kernel-module-management/ci/kmm-kmod/*.ko /opt/lib/modules/${KERNEL_VERSION}/
    RUN /usr/sbin/depmod -b /opt
---
apiVersion: kmm.sigs.x-k8s.io/v1beta1
kind: Module
metadata:
  name: example-module
  namespace: <namespace>
    2 
    
spec:
  moduleLoader:
    serviceAccountName: default
    3 
    
    container:
      modprobe:
        moduleName: simple_kmod
      kernelMappings:
        - regexp: '^.*\.x86_64$'
          containerImage: <final_driver_container_name>
          build:
            dockerfileConfigMap:
              name: example-module-dockerfile
          sign:
            keySecret:
              name: <private_key_secret_name>
            certSecret:
              name: <certificate_secret_name>
            filesToSign:
              - /opt/lib/modules/4.18.0-348.2.1.el8_5.x86_64/kmm_ci_a.ko
  imageRepoSecret:
    4 
    
    name: repo-pull-secret
  selector: # top-level selector
    kubernetes.io/arch: amd64
    Copy to Clipboard Toggle word wrap
1 2
기본값을 유효한 네임스페이스로 바꾸세요.
3
기본 serviceAccountName 에는 권한이 있는 모듈을 실행하는 데 필요한 권한이 없습니다. 서비스 계정 생성에 대한 자세한 내용은 이 섹션의 "해결 리소스"의 "서비스 계정 생성"을 참조하십시오.
4
DaemonSet 객체의 imagePullSecrets 로 사용되며 빌드 및 서명 기능을 끌어오고 푸시하는 데 사용됩니다.

4.15. 커널 모듈 스케줄링을 위한 허용 오차 사용
링크 복사

커널 모듈을 업그레이드하기 전에 노드에서 작업 부하를 대피시켜야 하는 상황이 있는데, 이는 테인트를 통해 수행할 수 있습니다. taint를 사용하면 노드에서 일치하는 허용 범위가 포함된 Pod만 예약할 수 있습니다.

그러나 커널 모듈 업그레이드와 같은 하우스키핑 작업을 실행하는 KMM(커널 모듈 관리) 포드를 허용하려면 허용 범위도 설정해야 합니다. 허용 범위는 노드에 추가된 오염과 일치해야 합니다.

사용자 정의 허용 범위를 커널 모듈에 생성하여 격리된 노드에서 선택된 KMM 포드를 예약할 수 있습니다. 예를 들어, 장치 드라이버를 업그레이드하는 동안 노드를 격리하는 동시에 드라이버 업그레이드를 수행하는 하우스키핑 포드를 실행할 수 있습니다.

ModuleSpec 필드는 포드 생성 중에 사용되는 KMM 포드에 대한 허용 오차를 전달하는 데 사용됩니다.

4.16. 커널 모듈 포드에 허용 범위 적용
링크 복사

오염과 허용은 효과 , 키 , 값 매개변수로 구성됩니다. 허용 범위에는 추가 연산자 와 tolerationSeconds 매개변수가 포함됩니다.

effect
일치하는 오염 효과를 나타냅니다. 비워 두면 모든 오염 효과가 일치합니다. effect를 설정할 때 유효한 값은 NoSchedule , PreferNoSchedule 또는 NoExecute 입니다.
key
관용이 적용되는 오염 키입니다. 비워 두면 모든 오염 키가 일치합니다. 키가 비어 있으면 연산자 매개변수를 Exists 로 설정해야 합니다. 이 조합은 모든 값과 모든 키와 일치합니다.
value
허용 오차가 일치하는 오염 값입니다. 연산자 매개변수가 Exists 인 경우 값은 비어 있어야 하며, 그렇지 않은 경우 일반 문자열을 사용합니다.
operator
키와 값의 관계를 나타냅니다. 유효한 연산자 매개변수는 Exists 및 Equal 입니다. 기본값은 같음 입니다. Exists는 값에 대한 와일드카드와 동일하므로 포드는 특정 카테고리의 모든 오염을 허용할 수 있습니다.
tolerationSeconds
허용 범위( NoExecute가 적용되어야 하며, 그렇지 않으면 이 필드는 무시됨)가 오염을 허용하는 기간을 나타냅니다. 기본적으로 설정되지 않으며 오염은 제거되지 않고 영구적으로 허용됩니다. 0과 음수 값은 0 으로 처리되어 시스템에서 즉시 제거됩니다.

노드 사양의 테인트 예

apiVersion: v1
kind: Node
metadata:
  name: <my_node>
#...
spec:
  taints:
  - effect: NoSchedule
    key: key1
    value: value1
#...
Copy to Clipboard Toggle word wrap

모듈 사양의 허용 범위 예시

apiVersion: kmm.sigs.x-k8s.io/v1beta1
kind: Module
metadata:
  name: <my_kmod>
spec:
  ...
  tolerations:
    effect: NoSchedule
    key: key1
    operator: Equal
    tolerationSeconds: 36000
    value: value1
Copy to Clipboard Toggle word wrap

허용 값은 노드에 추가된 오염과 일치해야 합니다. 톨러레이션은 테인트와 일치합니다.

  • operator 매개변수가 Equal로 설정된 경우:

    • key 매개변수는 동일합니다.
    • value 매개변수는 동일합니다.
    • effect 매개변수는 동일합니다.

  • operator 매개변수가 Exists로 설정된 경우:

    • key 매개변수는 동일합니다.
    • effect 매개변수는 동일합니다.

4.17. KMM 허브 앤 스포크
링크 복사

허브 앤 스포크 시나리오에서는 많은 스포크 클러스터가 중앙의 강력한 허브 클러스터에 연결됩니다. 커널 모듈 관리(KMM)는 허브 앤 스포크 환경에서 작동하기 위해 Red Hat Advanced Cluster Management(RHACM)에 의존합니다.

KMM은 KMM 기능을 분리하여 허브 앤 스포크 환경과 호환됩니다. ManagedClusterModule 사용자 정의 리소스 정의(CRD)는 기존 모듈 CRD를 래핑하고 선택한 Spoke 클러스터로 확장하기 위해 제공됩니다. 또한 허브 클러스터에서 이미지와 서명 모듈을 구축하는 새로운 독립형 컨트롤러인 KMM-Hub도 제공됩니다.

허브 앤 스포크 설정에서 스포크는 허브 클러스터에서 중앙 관리되는 집중적이고 리소스가 제한된 클러스터입니다. 스포크는 리소스를 많이 사용하는 기능이 비활성화된 KMM의 단일 클러스터 버전을 실행합니다. KMM을 이러한 환경에 적용하려면 스포크에서 실행되는 작업 부하를 최소한으로 줄이고, 허브에서 비용이 많이 드는 작업을 처리해야 합니다.

커널 모듈 이미지를 빌드하고 .ko 파일에 서명하는 작업은 허브에서 실행해야 합니다. 모듈 로더와 장치 플러그인 DaemonSets 의 스케줄링은 스포크에서만 발생할 수 있습니다.

4.17.1. KMM-Hub
링크 복사

KMM 프로젝트는 허브 클러스터 전용 KMM 에디션인 KMM-Hub를 제공합니다. KMM-Hub는 스포크에서 실행되는 모든 커널 버전을 모니터링하고 클러스터에서 커널 모듈을 받아야 하는 노드를 결정합니다.

KMM-Hub는 이미지 빌드, kmod 서명과 같은 모든 컴퓨팅 집약적 작업을 실행하고, RHACM을 통해 스포크로 전송될 수 있도록 축소된 모듈을 준비합니다.

참고

KMM-Hub를 사용하여 허브 클러스터에 커널 모듈을 로드할 수 없습니다. 커널 모듈을 로드하려면 KMM 일반 버전을 설치하세요.

4.17.2. KMM-Hub 설치
링크 복사

다음 방법 중 하나를 사용하여 KMM-Hub를 설치할 수 있습니다.

  • OLM(Operator Lifecycle Manager)을 사용하여
  • KMM 리소스 생성
4.17.2.1. Operator Lifecycle Manager를 사용하여 KMM-Hub 설치
링크 복사

OpenShift 콘솔의 운영자 섹션을 사용하여 KMM-Hub를 설치합니다.

4.17.2.2. KMM 리소스를 생성하여 KMM-Hub 설치
링크 복사

프로세스

  • KMM-Hub를 프로그래밍 방식으로 설치하려면 다음 리소스를 사용하여 Namespace , OperatorGroup 및 Subscription 리소스를 만들 수 있습니다. 
---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-kmm-hub
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: kernel-module-management-hub
  namespace: openshift-kmm-hub
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kernel-module-management-hub
  namespace: openshift-kmm-hub
spec:
  channel: stable
  installPlanApproval: Automatic
  name: kernel-module-management-hub
  source: redhat-operators
  sourceNamespace: openshift-marketplace
Copy to Clipboard Toggle word wrap

4.17.3. ManagedClusterModule CRD 사용
링크 복사

ManagedClusterModule 사용자 정의 리소스 정의(CRD)를 사용하여 스포크 클러스터에서 커널 모듈 배포를 구성합니다. 이 CRD는 클러스터 범위이며 모듈 사양을 래핑하고 다음과 같은 추가 필드를 추가합니다. 

apiVersion: hub.kmm.sigs.x-k8s.io/v1beta1
kind: ManagedClusterModule
metadata:
  name: <my-mcm>
  # No namespace, because this resource is cluster-scoped.
spec:
  moduleSpec:
1 

    selector:
2 

      node-wants-my-mcm: 'true'

  spokeNamespace: <some-namespace>
3 


  selector:
4 

    wants-my-mcm: 'true'
Copy to Clipboard Toggle word wrap
1
moduleSpec : Module 리소스와 유사한 moduleLoader 및 devicePlugin 섹션을 포함합니다.
2
ManagedCluster 내에서 노드를 선택합니다.
3
모듈 이 생성되어야 하는 네임스페이스를 지정합니다.
4
ManagedCluster 객체를 선택합니다.

.spec.moduleSpec 에 빌드 또는 서명 지침이 있는 경우 해당 Pod는 운영자 네임스페이스의 허브 클러스터에서 실행됩니다.

.spec.selector matches가 하나 이상의 ManagedCluster 리소스와 일치하는 경우 KMM-Hub는 해당 네임스페이스에 ManifestWork 리소스를 생성합니다. ManifestWork 에는 축소된 모듈 리소스가 포함되어 있으며, 커널 매핑은 보존되지만 모든 빌드 및 서명 하위 섹션은 제거됩니다. 태그로 끝나는 이미지 이름을 포함하는 containerImage 필드는 해당 다이제스트에 대응하는 이미지로 대체됩니다.

4.17.4. 스포크에서 KMM 실행
링크 복사

스포크에 KMM(커널 모듈 관리)을 설치한 후에는 더 이상 작업이 필요하지 않습니다. 허브에서 ManagedClusterModule 객체를 생성하여 스포크 클러스터에 커널 모듈을 배포합니다.

프로세스

RHACM 정책 객체를 통해 스포크 클러스터에 KMM을 설치할 수 있습니다. 정책은 OperatorHub에서 KMM을 설치하고 경량 스포크 모드로 실행하는 것 외에도, RHACM 에이전트에서 모듈 리소스를 관리하는 데 필요한 추가 RBAC를 구성합니다.

  • 다음 RHACM 정책을 사용하여 스포크 클러스터에 KMM을 설치하세요. 

    ---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: install-kmm
spec:
  remediationAction: enforce
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: install-kmm
        spec:
          severity: high
          object-templates:
          - complianceType: mustonlyhave
            objectDefinition:
              apiVersion: v1
              kind: Namespace
              metadata:
                name: openshift-kmm
          - complianceType: mustonlyhave
            objectDefinition:
              apiVersion: operators.coreos.com/v1
              kind: OperatorGroup
              metadata:
                name: kmm
                namespace: openshift-kmm
              spec:
                upgradeStrategy: Default
          - complianceType: mustonlyhave
            objectDefinition:
              apiVersion: operators.coreos.com/v1alpha1
              kind: Subscription
              metadata:
                name: kernel-module-management
                namespace: openshift-kmm
              spec:
                channel: stable
                config:
                  env:
                    - name: KMM_MANAGED
    1 
    
                      value: "1"
                installPlanApproval: Automatic
                name: kernel-module-management
                source: redhat-operators
                sourceNamespace: openshift-marketplace
          - complianceType: mustonlyhave
            objectDefinition:
              apiVersion: rbac.authorization.k8s.io/v1
              kind: ClusterRole
              metadata:
                name: kmm-module-manager
              rules:
                - apiGroups: [kmm.sigs.x-k8s.io]
                  resources: [modules]
                  verbs: [create, delete, get, list, patch, update, watch]
          - complianceType: mustonlyhave
            objectDefinition:
              apiVersion: rbac.authorization.k8s.io/v1
              kind: ClusterRoleBinding
              metadata:
                name: klusterlet-kmm
              subjects:
              - kind: ServiceAccount
                name: klusterlet-work-sa
                namespace: open-cluster-management-agent
              roleRef:
                kind: ClusterRole
                name: kmm-module-manager
                apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: all-managed-clusters
spec:
  clusterSelector:
    2 
    
    matchExpressions: []
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: install-kmm
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: all-managed-clusters
subjects:
  - apiGroup: policy.open-cluster-management.io
    kind: Policy
    name: install-kmm
    Copy to Clipboard Toggle word wrap
    1
    스포크 클러스터에서 KMM을 실행할 때 이 환경 변수가 필요합니다.
    2
    spec.clusterSelector 필드는 특정 클러스터만 대상으로 사용자 정의할 수 있습니다.

4.18. 커널 모듈에 대한 업그레이드 사용자 정의
링크 복사

필요한 경우 노드 재부팅을 포함하여 노드에서 유지보수 작업을 실행하는 동안 커널 모듈을 업그레이드하려면 다음 절차를 사용하십시오. 클러스터에서 실행되는 워크로드에 미치는 영향을 최소화하려면 한 번에 하나의 노드인 커널 업그레이드 프로세스를 순차적으로 실행합니다.

참고

이 절차에서는 커널 모듈을 사용하는 워크로드에 대한 지식이 필요하며 클러스터 관리자가 관리해야 합니다.

사전 요구 사항

  • 업그레이드하기 전에 커널 모듈에서 사용하는 모든 노드에 kmm.node.kubernetes.io/version-module.<module_namespace>.<module_name>=$moduleVersion 레이블을 설정합니다.
  • 노드의 모든 사용자 애플리케이션 워크로드를 종료하거나 다른 노드로 이동합니다.
  • 현재 로드된 커널 모듈을 언로드합니다.
  • 사용자 워크로드(커널 모듈에 액세스하는 클러스터에서 실행 중인 애플리케이션)가 커널 모듈 언로드 전에 노드에서 실행되지 않고 새 커널 모듈 버전이 로드된 후 노드에서 워크로드가 다시 실행되고 있는지 확인합니다.

프로세스

  1. 노드에서 KMM이 관리하는 장치 플러그인이 언로드되었는지 확인하세요.

  2. 모듈 사용자 정의 리소스(CR)에서 다음 필드를 업데이트합니다.

    • containerImage (해당 커널 버전)

    • version

      업데이트는 atomic이어야 합니다. 즉 containerImage 및 version 필드를 동시에 업데이트해야 합니다.

  3. 업그레이드 중인 노드에서 커널 모듈을 사용하여 모든 워크로드를 종료합니다.

  4. 노드에서 kmm.node.kubernetes.io/version-module.<module_namespace>.<module_name> 레이블을 제거합니다. 다음 명령을 실행하여 노드에서 커널 모듈을 언로드합니다. 

    $ oc label node/<node_name> kmm.node.kubernetes.io/version-module.<module_namespace>.<module_name>-
    Copy to Clipboard Toggle word wrap

  5. 필요한 경우 클러스터 관리자로서 커널 모듈 업그레이드를 위해 노드에 필요한 추가 유지 관리를 수행합니다.

    추가 업그레이드가 필요하지 않은 경우 kmm.node.kubernetes.io/version-module.<module_namespace>.<module_name> 레이블 값을 Module에 설정된 대로 새 $moduleVersion 으로 업데이트하여 3~6단계를 건너뛸 수 있습니다.

  6. 다음 명령을 실행하여 kmm.node.kubernetes.io/version-module.<module_namespace>.<module_name>=$moduleVersion 레이블을 노드에 추가합니다. $moduleVersion은 모듈 CR의 버전 필드의 새 값과 같아야 합니다. 

    $ oc label node/<node_name> kmm.node.kubernetes.io/version-module.<module_namespace>.<module_name>=<desired_version>
    Copy to Clipboard Toggle word wrap
    참고

    레이블 이름에 대한 Kubernetes의 제한으로 인해 모듈 이름과 네임스페이스의 결합 길이는 39자를 초과할 수 없습니다.

  7. 노드에서 커널 모듈을 활용하는 모든 워크로드를 복원합니다.
  8. 노드에서 KMM이 관리하는 장치 플러그인을 다시 로드합니다.

4.19. Day 1 커널 모듈 로드
링크 복사

커널 모듈 관리(KMM)는 일반적으로 Day 2 Operator입니다. 커널 모듈은 RHCOS(Linux) 서버의 초기화를 완료한 후에만 로드됩니다. 그러나 일부 시나리오에서는 커널 모듈을 이전 단계에서 로드해야 합니다. Day 1 기능을 사용하면 Linux systemd 초기화 단계에서 MCO(Machine Config Operator)를 사용하여 커널 모듈을 로드할 수 있습니다.

4.19.1. Day 1 지원 사용 사례
링크 복사

Day 1 기능은 제한된 수의 사용 사례를 지원합니다. 주요 사용 사례는 NetworkManager 서비스 초기화 전에 OOT(out-of-tree) 커널 모듈을 로드하도록 허용하는 것입니다. initramfs 단계에서 커널 모듈 로드를 지원하지 않습니다.

Day 1 기능에 필요한 조건은 다음과 같습니다.

  • 커널 모듈이 커널에 로드되지 않습니다.
  • in-tree 커널 모듈은 커널에 로드되지만 OOT 커널 모듈로 언로드하고 교체할 수 있습니다. 즉 in-tree 모듈은 다른 커널 모듈에서 참조되지 않습니다.
  • Day 1 기능이 작동하려면 노드에 작동하는 작동 중인 네트워크 인터페이스, 즉 해당 인터페이스의 in-tree 커널 드라이버가 있어야 합니다. OOT 커널 모듈은 기능 네트워크 드라이버를 대체할 네트워크 드라이버일 수 있습니다.

4.19.2. OOT 커널 모듈 로드 흐름
링크 복사

OOT(out-of-tree) 커널 모듈을 로드하면 MCO(Machine Config Operator)가 사용됩니다. 흐름 시퀀스는 다음과 같습니다.

프로세스

  1. 기존 실행 중인 클러스터에 MachineConfig 리소스를 적용합니다. 업데이트해야 하는 필수 노드를 식별하려면 적절한 MachineConfigPool 리소스를 생성해야 합니다.
  2. MCO는 노드별로 재부팅 노드를 적용합니다. 재부팅된 노드에서 두 개의 새 systemd 서비스 pull service 및 load 서비스가 배포됩니다.
  3. load 서비스는 NetworkConfiguration 서비스 전에 실행되도록 구성되어 있습니다. 서비스는 사전 정의된 커널 모듈 이미지를 가져온 다음 해당 이미지를 사용하여 in-tree 모듈을 언로드하고 OOT 커널 모듈을 로드하려고 합니다.
  4. pull 서비스는 NetworkManager 서비스 후에 실행되도록 구성되어 있습니다. 이 서비스는 사전 구성된 커널 모듈 이미지가 노드의 파일 시스템에 있는지 확인합니다. 이 경우 서비스가 정상적으로 존재하며 서버는 부팅 프로세스를 계속합니다. 그렇지 않으면 이미지를 노드로 가져와서 나중에 노드를 재부팅합니다.

4.19.3. 커널 모듈 이미지
링크 복사

Day 1 기능은 Day 2 KMM 빌드에서 활용하는 동일한 DTK 기반 이미지를 사용합니다. 트리 외부 커널 모듈은 /opt/lib/modules/${kernelVersion} 에 있어야 합니다.

4.19.4. in-tree 모듈 교체
링크 복사

Day 1 기능은 항상 in-tree 커널 모듈을 OOT 버전으로 대체하려고 합니다. in-tree 커널 모듈이 로드되지 않으면 흐름에 영향을 미치지 않습니다. 서비스는 OOT 커널 모듈을 진행하여 로드합니다.

4.19.5. MCO yaml 생성
링크 복사

KMM은 Day 1 기능에 대한 MCO YAML 매니페스트를 생성하는 API를 제공합니다. 

ProduceMachineConfig(machineConfigName, machineConfigPoolRef, kernelModuleImage, kernelModuleName string) (string, error)
Copy to Clipboard Toggle word wrap

반환된 출력은 적용할 MCO YAML 매니페스트의 문자열 표현입니다. 이 YAML을 적용하는 것은 고객에게 달려 있습니다.

매개변수는 다음과 같습니다.

machineConfigName
MCO YAML 매니페스트 이름입니다. 이 매개변수는 MCO YAML 매니페스트 메타데이터의 name 매개변수로 설정됩니다.
machineConfigPoolRef
대상 노드를 식별하는 데 사용되는 MachineConfigPool 이름입니다.
kernelModuleImage
OOT 커널 모듈이 포함된 컨테이너 이미지의 이름입니다.
kernelModuleName
OOT 커널 모듈의 이름입니다. 이 매개변수는 in-tree 커널 모듈을 언로드하고(커널에 로드된 경우) OOT 커널 모듈을 로드하는 데 사용됩니다.

API는 KMM 소스 코드의 pkg/mcproducer 패키지에 있습니다. KMM Operator는 Day 1 기능을 사용하기 위해 실행할 필요가 없습니다. pkg/mcproducer 패키지를 operator/utility 코드로 가져와서 API를 호출한 다음 생성된 MCO YAML을 클러스터에 적용해야 합니다.

4.19.6. MachineConfigPool
링크 복사

MachineConfigPool 은 적용된 MCO의 영향을 받는 노드 컬렉션을 식별합니다. 

kind: MachineConfigPool
metadata:
  name: sfc
spec:
  machineConfigSelector:
1 

    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker, sfc]}
  nodeSelector:
2 

    matchLabels:
      node-role.kubernetes.io/sfc: ""
  paused: false
  maxUnavailable: 1
Copy to Clipboard Toggle word wrap
1
MachineConfig의 레이블과 일치합니다.
2
노드의 레이블과 일치합니다.

OCP 클러스터에는 사전 정의된 MachineConfigPool 이 있습니다.

  • worker: 클러스터의 모든 작업자 노드 지정
  • master: 클러스터의 모든 마스터 노드를 대상으로 지정

마스터 MachineConfigPool을 대상으로 하도록 다음 MachineConfig를 정의합니다. 

metadata:
  labels:
    machineconfiguration.opensfhit.io/role: master
Copy to Clipboard Toggle word wrap

작업자 MachineConfigPool을 대상으로 하도록 다음 MachineConfig를 정의합니다. 

metadata:
  labels:
    machineconfiguration.opensfhit.io/role: worker
Copy to Clipboard Toggle word wrap

4.20. 디버깅 및 문제 해결
링크 복사

드라이버 컨테이너의 kmods가 서명되지 않았거나 잘못된 키로 서명된 경우 컨테이너는 PostStartHookError 또는 CrashLoopBackOff 상태를 입력할 수 있습니다. 이 시나리오에 다음 메시지를 표시하는 컨테이너에서 oc describe 명령을 실행하여 확인할 수 있습니다. 

modprobe: ERROR: could not insert '<your_kmod_name>': Required key not available
Copy to Clipboard Toggle word wrap

4.21. KMM 펌웨어 지원
링크 복사

커널 모듈은 파일 시스템에서 펌웨어 파일을 로드해야 하는 경우가 있습니다. KMM은 kmod 이미지의 펌웨어 파일을 노드의 파일 시스템으로 복사할 수 있도록 지원합니다.

modprobe 명령을 실행하여 커널 모듈을 삽입하기 전에 .spec.moduleLoader.container.modprobe.firmwarePath 의 콘텐츠가 노드의 /var/lib/firmware 경로에 복사됩니다.

Pod가 종료되면 modprobe -r 명령을 실행하기 전에 모든 파일과 빈 디렉터리가 해당 위치에서 제거됩니다.

4.21.2. kmod 이미지 빌드
링크 복사

프로세스

  • 커널 모듈 자체를 빌드하는 것 외에도 빌더 이미지에 바이너리 펌웨어를 포함합니다. 

    FROM registry.redhat.io/ubi9/ubi-minimal as builder

# Build the kmod

RUN ["mkdir", "/firmware"]
RUN ["curl", "-o", "/firmware/firmware.bin", "https://artifacts.example.com/firmware.bin"]

FROM registry.redhat.io/ubi9/ubi-minimal

# Copy the kmod, install modprobe, run depmod

COPY --from=builder /firmware /firmware
    Copy to Clipboard Toggle word wrap

4.21.3. 모듈 리소스 튜닝
링크 복사

프로세스

  • Module CR(사용자 정의 리소스)에서 .spec.moduleLoader.container.modprobe.firmwarePath 를 설정합니다. 

    apiVersion: kmm.sigs.x-k8s.io/v1beta1
kind: Module
metadata:
  name: my-kmod
spec:
  moduleLoader:
    container:
      modprobe:
        moduleName: my-kmod  # Required

        firmwarePath: /firmware
    1
    Copy to Clipboard Toggle word wrap
    1
    선택 사항: /firmware/* 를 노드의 /var/lib/firmware/ 로 복사합니다.

4.22. Day 0 through Day 2 kmod 설치
링크 복사

KMM(커널 모듈 관리) 없이 0일에서 2일까지 일부 커널 모듈(kmods)을 설치할 수 있습니다. 이는 kmods를 KMM으로 전환하는 데 도움이 될 수 있습니다.

다음 기준을 사용하여 적절한 kmod 설치를 확인합니다.

0일

노드가 클러스터에서 준비 되도록 하는 데 필요한 가장 기본적인 kmod입니다. 이러한 유형의 kmods의 예는 다음과 같습니다.

  • 부팅 프로세스의 일부로 rootFS를 마운트하는 데 필요한 스토리지 드라이버
  • 머신이 부트스트랩 노드의 machine-config-server 에 액세스하여 ignition을 가져오고 클러스터에 가입하는 데 필요한 네트워크 드라이버
1일

노드가 클러스터에서 Ready 가 되는 데 필요하지 않지만 노드가 Ready되면 언로드할 수 없는 kmods입니다.

이러한 유형의 kmod는 NetworkManager 가 의존하는 동안 오래된 in-tree 드라이버를 교체하여 NIC의 전체 가능성을 악용하는 OOT(out-of-tree) 네트워크 드라이버입니다. 노드가 준비 되면 NetworkManager 종속성으로 인해 드라이버를 언로드할 수 없습니다.

2일

클러스터 인프라(예: 연결)를 방해하지 않고 커널에 동적으로 로드하거나 제거할 수 있는kmod입니다.

이러한 유형의 kmods의 예는 다음과 같습니다.

  • GPU Operator
  • 보조 네트워크 어댑터
  • FGA(Field-programmable gate arrays)

4.22.1. 계층화 배경
링크 복사

0일 차가 클러스터에 설치되면 MCO(Machine Config Operator)를 통해 계층 지정이 적용되고 OpenShift Container Platform 업그레이드로 인해 노드 업그레이드가 트리거되지 않습니다.

노드의 운영 체제가 동일하게 유지되므로 새 기능을 추가하는 경우에만 드라이버를 다시 컴파일해야 합니다.

4.22.2. 라이프사이클 관리
링크 복사

KMM을 활용하여 드라이버에서 허용하면 재부팅하지 않고 kmods의 Day 0 through Day 2 라이프사이클을 관리할 수 있습니다.

참고

이는 업그레이드에 노드 재부팅이 필요한 경우(예: initramfs 파일을 다시 빌드해야 하는 경우) 작동하지 않습니다.

라이프사이클 관리에 다음 옵션 중 하나를 사용합니다.

4.22.2.1. kmod를 in-tree 드라이버로 처리
링크 복사

kmods를 업그레이드하려면 이 방법을 사용합니다. 이 경우 kmod를 in-tree 드라이버로 처리하고 inTreeRemoval 필드가 있는 클러스터에 모듈을 생성하여 이전 버전의 드라이버를 언로드합니다.

kmod를 in-tree 드라이버로 취급하는 다음과 같은 특성을 기록해 둡니다.

  • KMM이 선택한 모든 노드에서 동시에 kmod를 언로드하고 로드하면 다운타임이 발생할 수 있습니다.
  • KMM은 단일 Pod를 사용하여 드라이버를 언로드하고 로드하기 때문에 드라이버를 제거하면 노드가 연결이 끊어집니다.
4.22.2.2. 순서가 지정된 업그레이드 사용
링크 복사

kmods가 이미 로드되어 있으므로 순서가 지정된 업그레이드(ordered_upgrade.md)를 사용하여 kmods를 나타내는 클러스터에 버전 지정된 모듈을 생성할 수 있습니다.

순서가 지정된 업그레이드를 사용하는 경우 다음과 같은 특징이 있습니다.

  • 업그레이드 속도와 동시에 업그레이드되는 노드 수를 제어하므로 클러스터 다운타임이 발생하지 않습니다. 따라서 다운타임 없이 업그레이드할 수 있습니다.
  • KMM은 언로드를 위해 두 개의 다른 작업자 Pod를 생성하고 로드를 위해 드라이버를 언로드하면 노드에 대한 연결이 끊어집니다. 이러한 Pod는 예약되지 않습니다.

4.23. KMM 문제 해결
링크 복사

KMM 설치 문제를 해결할 때 로그를 모니터링하여 문제가 발생하는 단계를 확인할 수 있습니다. 그런 다음 해당 단계와 관련된 진단 데이터를 검색합니다.

4.23.1. Operator 로그 읽기
링크 복사

다음 예제와 같이 oc logs 명령을 사용하여 Operator 로그를 읽을 수 있습니다.

KMM 컨트롤러의 명령 예

$ oc logs -fn openshift-kmm deployments/kmm-operator-controller
Copy to Clipboard Toggle word wrap

KMM Webhook 서버 명령 예

$ oc logs -fn openshift-kmm deployments/kmm-operator-webhook-server
Copy to Clipboard Toggle word wrap

KMM-Hub 컨트롤러의 명령 예

$ oc logs -fn openshift-kmm-hub deployments/kmm-operator-hub-controller
Copy to Clipboard Toggle word wrap

KMM-Hub 웹 후크 서버의 예

$ oc logs -fn openshift-kmm deployments/kmm-operator-hub-webhook-server
Copy to Clipboard Toggle word wrap

4.23.2. 이벤트 관찰
링크 복사

다음 방법을 사용하여 KMM 이벤트를 봅니다.

빌드 및 서명

KMM은 kmod 이미지 빌드를 시작하거나 결과를 관찰할 때마다 이벤트를 게시합니다. 이러한 이벤트는 Module 오브젝트에 연결되어 있으며 다음 예제와 같이 oc describe module 명령의 출력 끝에 있습니다. 

$ oc describe modules.kmm.sigs.x-k8s.io kmm-ci-a
[...]
Events:
  Type    Reason          Age                From  Message
  ----    ------          ----               ----  -------
  Normal  BuildCreated    2m29s              kmm   Build created for kernel 6.6.2-201.fc39.x86_64
  Normal  BuildSucceeded  63s                kmm   Build job succeeded for kernel 6.6.2-201.fc39.x86_64
  Normal  SignCreated     64s (x2 over 64s)  kmm   Sign created for kernel 6.6.2-201.fc39.x86_64
  Normal  SignSucceeded   57s                kmm   Sign job succeeded for kernel 6.6.2-201.fc39.x86_64
Copy to Clipboard Toggle word wrap
모듈 로드 또는 언로드

KMM은 노드에서 커널 모듈을 성공적으로 로드하거나 언로드할 때마다 이벤트를 게시합니다. 이러한 이벤트는 Node 객체에 첨부되며 다음 예와 같이 oc describe node 명령의 출력 끝에서 사용할 수 있습니다. 

$ oc describe node my-node
[...]
Events:
  Type    Reason          Age    From  Message
  ----    ------          ----   ----  -------
[...]
  Normal  ModuleLoaded    4m17s  kmm   Module default/kmm-ci-a loaded into the kernel
  Normal  ModuleUnloaded  2s     kmm   Module default/kmm-ci-a unloaded from the kernel
Copy to Clipboard Toggle word wrap

4.23.3. must-gather 툴 사용
링크 복사

oc adm must-gather 명령은 지원 번들을 수집하고 Red Hat 지원에 디버깅 정보를 제공하는 데 선호되는 방법입니다. 다음 섹션에 설명된 대로 적절한 인수를 사용하여 명령을 실행하여 특정 정보를 수집합니다.

4.23.3.1. KMM에 대한 데이터 수집
링크 복사

프로세스

  1. KMM Operator 컨트롤러 관리자의 데이터를 수집합니다.

    1. MUST_GATHER_IMAGE 변수를 설정합니다. 

      $ export MUST_GATHER_IMAGE=$(oc get deployment -n openshift-kmm kmm-operator-controller -ojsonpath='{.spec.template.spec.containers[?(@.name=="manager")].env[?(@.name=="RELATED_IMAGE_MUST_GATHER")].value}')
$ oc adm must-gather --image="${MUST_GATHER_IMAGE}" -- /usr/bin/gather
      Copy to Clipboard Toggle word wrap
      참고

      사용자 정의 네임스페이스에 KMM을 설치한 경우 -n <namespace> 스위치를 사용하여 네임스페이스를 지정합니다.

    2. must-gather 툴을 실행합니다. 

      $ oc adm must-gather --image="${MUST_GATHER_IMAGE}" -- /usr/bin/gather
      Copy to Clipboard Toggle word wrap

  2. Operator 로그를 표시합니다. 

    $ oc logs -fn openshift-kmm deployments/kmm-operator-controller
    Copy to Clipboard Toggle word wrap

    예 4.1. 출력 예

    I0228 09:36:37.352405       1 request.go:682] Waited for 1.001998746s due to client-side throttling, not priority and fairness, request: GET:https://172.30.0.1:443/apis/machine.openshift.io/v1beta1?timeout=32s
I0228 09:36:40.767060       1 listener.go:44] kmm/controller-runtime/metrics "msg"="Metrics server is starting to listen" "addr"="127.0.0.1:8080"
I0228 09:36:40.769483       1 main.go:234] kmm/setup "msg"="starting manager"
I0228 09:36:40.769907       1 internal.go:366] kmm "msg"="Starting server" "addr"={"IP":"127.0.0.1","Port":8080,"Zone":""} "kind"="metrics" "path"="/metrics"
I0228 09:36:40.770025       1 internal.go:366] kmm "msg"="Starting server" "addr"={"IP":"::","Port":8081,"Zone":""} "kind"="health probe"
I0228 09:36:40.770128       1 leaderelection.go:248] attempting to acquire leader lease openshift-kmm/kmm.sigs.x-k8s.io...
I0228 09:36:40.784396       1 leaderelection.go:258] successfully acquired lease openshift-kmm/kmm.sigs.x-k8s.io
I0228 09:36:40.784876       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="Module" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="Module" "source"="kind source: *v1beta1.Module"
I0228 09:36:40.784925       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="Module" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="Module" "source"="kind source: *v1.DaemonSet"
I0228 09:36:40.784968       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="Module" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="Module" "source"="kind source: *v1.Build"
I0228 09:36:40.785001       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="Module" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="Module" "source"="kind source: *v1.Job"
I0228 09:36:40.785025       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="Module" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="Module" "source"="kind source: *v1.Node"
I0228 09:36:40.785039       1 controller.go:193] kmm "msg"="Starting Controller" "controller"="Module" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="Module"
I0228 09:36:40.785458       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="PodNodeModule" "controllerGroup"="" "controllerKind"="Pod" "source"="kind source: *v1.Pod"
I0228 09:36:40.786947       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="PreflightValidation" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidation" "source"="kind source: *v1beta1.PreflightValidation"
I0228 09:36:40.787406       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="PreflightValidation" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidation" "source"="kind source: *v1.Build"
I0228 09:36:40.787474       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="PreflightValidation" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidation" "source"="kind source: *v1.Job"
I0228 09:36:40.787488       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="PreflightValidation" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidation" "source"="kind source: *v1beta1.Module"
I0228 09:36:40.787603       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="NodeKernel" "controllerGroup"="" "controllerKind"="Node" "source"="kind source: *v1.Node"
I0228 09:36:40.787634       1 controller.go:193] kmm "msg"="Starting Controller" "controller"="NodeKernel" "controllerGroup"="" "controllerKind"="Node"
I0228 09:36:40.787680       1 controller.go:193] kmm "msg"="Starting Controller" "controller"="PreflightValidation" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidation"
I0228 09:36:40.785607       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="imagestream" "controllerGroup"="image.openshift.io" "controllerKind"="ImageStream" "source"="kind source: *v1.ImageStream"
I0228 09:36:40.787822       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="preflightvalidationocp" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidationOCP" "source"="kind source: *v1beta1.PreflightValidationOCP"
I0228 09:36:40.787853       1 controller.go:193] kmm "msg"="Starting Controller" "controller"="imagestream" "controllerGroup"="image.openshift.io" "controllerKind"="ImageStream"
I0228 09:36:40.787879       1 controller.go:185] kmm "msg"="Starting EventSource" "controller"="preflightvalidationocp" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidationOCP" "source"="kind source: *v1beta1.PreflightValidation"
I0228 09:36:40.787905       1 controller.go:193] kmm "msg"="Starting Controller" "controller"="preflightvalidationocp" "controllerGroup"="kmm.sigs.x-k8s.io" "controllerKind"="PreflightValidationOCP"
I0228 09:36:40.786489       1 controller.go:193] kmm "msg"="Starting Controller" "controller"="PodNodeModule" "controllerGroup"="" "controllerKind"="Pod"
    Copy to Clipboard Toggle word wrap
4.23.3.2. KMM-Hub에 대한 데이터 수집
링크 복사

프로세스

  1. KMM Operator hub 컨트롤러 관리자의 데이터를 수집합니다.

    1. MUST_GATHER_IMAGE 변수를 설정합니다. 

      $ export MUST_GATHER_IMAGE=$(oc get deployment -n openshift-kmm-hub kmm-operator-hub-controller -ojsonpath='{.spec.template.spec.containers[?(@.name=="manager")].env[?(@.name=="RELATED_IMAGE_MUST_GATHER")].value}')
$ oc adm must-gather --image="${MUST_GATHER_IMAGE}" -- /usr/bin/gather -u
      Copy to Clipboard Toggle word wrap
      참고

      사용자 정의 네임스페이스에 KMM을 설치한 경우 -n <namespace> 스위치를 사용하여 네임스페이스를 지정합니다.

    2. must-gather 툴을 실행합니다. 

      $ oc adm must-gather --image="${MUST_GATHER_IMAGE}" -- /usr/bin/gather -u
      Copy to Clipboard Toggle word wrap

  2. Operator 로그를 표시합니다. 

    $ oc logs -fn openshift-kmm-hub deployments/kmm-operator-hub-controller
    Copy to Clipboard Toggle word wrap

    예 4.2. 출력 예

    I0417 11:34:08.807472       1 request.go:682] Waited for 1.023403273s due to client-side throttling, not priority and fairness, request: GET:https://172.30.0.1:443/apis/tuned.openshift.io/v1?timeout=32s
I0417 11:34:12.373413       1 listener.go:44] kmm-hub/controller-runtime/metrics "msg"="Metrics server is starting to listen" "addr"="127.0.0.1:8080"
I0417 11:34:12.376253       1 main.go:150] kmm-hub/setup "msg"="Adding controller" "name"="ManagedClusterModule"
I0417 11:34:12.376621       1 main.go:186] kmm-hub/setup "msg"="starting manager"
I0417 11:34:12.377690       1 leaderelection.go:248] attempting to acquire leader lease openshift-kmm-hub/kmm-hub.sigs.x-k8s.io...
I0417 11:34:12.378078       1 internal.go:366] kmm-hub "msg"="Starting server" "addr"={"IP":"127.0.0.1","Port":8080,"Zone":""} "kind"="metrics" "path"="/metrics"
I0417 11:34:12.378222       1 internal.go:366] kmm-hub "msg"="Starting server" "addr"={"IP":"::","Port":8081,"Zone":""} "kind"="health probe"
I0417 11:34:12.395703       1 leaderelection.go:258] successfully acquired lease openshift-kmm-hub/kmm-hub.sigs.x-k8s.io
I0417 11:34:12.396334       1 controller.go:185] kmm-hub "msg"="Starting EventSource" "controller"="ManagedClusterModule" "controllerGroup"="hub.kmm.sigs.x-k8s.io" "controllerKind"="ManagedClusterModule" "source"="kind source: *v1beta1.ManagedClusterModule"
I0417 11:34:12.396403       1 controller.go:185] kmm-hub "msg"="Starting EventSource" "controller"="ManagedClusterModule" "controllerGroup"="hub.kmm.sigs.x-k8s.io" "controllerKind"="ManagedClusterModule" "source"="kind source: *v1.ManifestWork"
I0417 11:34:12.396430       1 controller.go:185] kmm-hub "msg"="Starting EventSource" "controller"="ManagedClusterModule" "controllerGroup"="hub.kmm.sigs.x-k8s.io" "controllerKind"="ManagedClusterModule" "source"="kind source: *v1.Build"
I0417 11:34:12.396469       1 controller.go:185] kmm-hub "msg"="Starting EventSource" "controller"="ManagedClusterModule" "controllerGroup"="hub.kmm.sigs.x-k8s.io" "controllerKind"="ManagedClusterModule" "source"="kind source: *v1.Job"
I0417 11:34:12.396522       1 controller.go:185] kmm-hub "msg"="Starting EventSource" "controller"="ManagedClusterModule" "controllerGroup"="hub.kmm.sigs.x-k8s.io" "controllerKind"="ManagedClusterModule" "source"="kind source: *v1.ManagedCluster"
I0417 11:34:12.396543       1 controller.go:193] kmm-hub "msg"="Starting Controller" "controller"="ManagedClusterModule" "controllerGroup"="hub.kmm.sigs.x-k8s.io" "controllerKind"="ManagedClusterModule"
I0417 11:34:12.397175       1 controller.go:185] kmm-hub "msg"="Starting EventSource" "controller"="imagestream" "controllerGroup"="image.openshift.io" "controllerKind"="ImageStream" "source"="kind source: *v1.ImageStream"
I0417 11:34:12.397221       1 controller.go:193] kmm-hub "msg"="Starting Controller" "controller"="imagestream" "controllerGroup"="image.openshift.io" "controllerKind"="ImageStream"
I0417 11:34:12.498335       1 filter.go:196] kmm-hub "msg"="Listing all ManagedClusterModules" "managedcluster"="local-cluster"
I0417 11:34:12.498570       1 filter.go:205] kmm-hub "msg"="Listed ManagedClusterModules" "count"=0 "managedcluster"="local-cluster"
I0417 11:34:12.498629       1 filter.go:238] kmm-hub "msg"="Adding reconciliation requests" "count"=0 "managedcluster"="local-cluster"
I0417 11:34:12.498687       1 filter.go:196] kmm-hub "msg"="Listing all ManagedClusterModules" "managedcluster"="sno1-0"
I0417 11:34:12.498750       1 filter.go:205] kmm-hub "msg"="Listed ManagedClusterModules" "count"=0 "managedcluster"="sno1-0"
I0417 11:34:12.498801       1 filter.go:238] kmm-hub "msg"="Adding reconciliation requests" "count"=0 "managedcluster"="sno1-0"
I0417 11:34:12.501947       1 controller.go:227] kmm-hub "msg"="Starting workers" "controller"="imagestream" "controllerGroup"="image.openshift.io" "controllerKind"="ImageStream" "worker count"=1
I0417 11:34:12.501948       1 controller.go:227] kmm-hub "msg"="Starting workers" "controller"="ManagedClusterModule" "controllerGroup"="hub.kmm.sigs.x-k8s.io" "controllerKind"="ManagedClusterModule" "worker count"=1
I0417 11:34:12.502285       1 imagestream_reconciler.go:50] kmm-hub "msg"="registered imagestream info mapping" "ImageStream"={"name":"driver-toolkit","namespace":"openshift"} "controller"="imagestream" "controllerGroup"="image.openshift.io" "controllerKind"="ImageStream" "dtkImage"="quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:df42b4785a7a662b30da53bdb0d206120cf4d24b45674227b16051ba4b7c3934" "name"="driver-toolkit" "namespace"="openshift" "osImageVersion"="412.86.202302211547-0" "reconcileID"="e709ff0a-5664-4007-8270-49b5dff8bae9"
    Copy to Clipboard Toggle word wrap

5장. 커널 모듈 관리 운영자 릴리스 노트
링크 복사

5.1. 커널 모듈 관리 운영자 2.2 릴리스 노트
링크 복사

5.1.1. 새로운 기능
링크 복사

  • KMM은 이제 워커 컨테이너에서 직접 HTTP 호출을 사용하는 대신 CRI-O 컨테이너 엔진을 사용하여 워커 포드에서 컨테이너 이미지를 가져옵니다. 자세한 내용은 예제 모듈 CR을 참조하세요.
  • 커널 모듈 관리(KMM) 운영자 이미지는 이제 rhel-els 이미지 대신 rhel-els -minimal 컨테이너 이미지를 기반으로 합니다. 이러한 변경으로 FIPS 규정을 준수하는 동시에 이미지 크기가 크게 줄었습니다.
  • 이 릴리스에서는 펌웨어 검색 경로가 업데이트되어 지정된 경로의 내용이 worker.setFirmwareClassPath에 지정된 경로(기본값: /var/lib/firmware)로 복사됩니다. 자세한 내용은 예제 모듈 CR을 참조하세요.
  • 정규 표현식과 일치하는 커널을 실행하는 각 노드에 대해 KMM은 이제 태그나 다이제스트를 포함했는지 확인합니다. 컨테이너 이미지에 태그나 다이제스트를 지정하지 않으면 검증 웹훅이 오류를 반환하고 모듈을 적용하지 않습니다. 자세한 내용은 예제 모듈 CR을 참조하세요.

5.2. 커널 모듈 관리 운영자 2.3 릴리스 노트
링크 복사

5.2.1. 새로운 기능
링크 복사

  • 이번 릴리스에서 KMM은 파트너의 테스트 연속성을 보장하기 위해 Golang 프로그래밍 언어 버전 1.23을 사용합니다.

5.3. 커널 모듈 관리 운영자 2.4 릴리스 노트
링크 복사

5.3.1. 새로운 기능 및 개선 사항
링크 복사

  • 이번 릴리스에서는 트리 외부 커널 드라이버를 로드하지 않고 대신 트리 내부 드라이버를 사용하고 장치 플러그인만 실행하도록 KMM(커널 모듈 관리) 모듈을 구성하는 옵션이 추가되었습니다. 자세한 내용은 장치 플러그인과 함께 트리 내 모듈 사용을 참조하세요.

  • 이 릴리스에서는 클러스터 및 KMM 운영자가 업그레이드되고 KMM이 다시 배포된 후에도 KMM 구성이 지속됩니다.

    이전 릴리스에서는 클러스터 또는 KMM을 업그레이드하거나, KMM을 다시 배포하는 펌웨어 경로와 같은 기본이 아닌 구성을 업그레이드하는 등의 다른 작업을 수행할 때 KMM을 다시 구성해야 할 필요가 있었습니다. 이번 릴리스에서는 이러한 작업에 관계없이 KMM 구성이 영구적으로 유지됩니다.

    자세한 내용은 커널 모듈 관리 운영자 구성을 참조하세요.

  • GPU 운영자 공급업체가 코드에서 KMM 기능을 복제할 필요가 없고, 대신 KMM을 그대로 사용할 수 있도록 KMM에 개선 사항이 추가되었습니다. 이러한 변경으로 운영자의 코드 크기, 테스트, 안정성이 크게 향상되었습니다.
  • 이 릴리스에서는 KMM이 더 이상 HTTP(S) 직접 요청을 사용하여 kmod 이미지가 있는지 확인하지 않습니다. 대신 CRI-O는 내부적으로 이미지를 확인하는 데 사용됩니다. 이를 통해 HTTP(S) 요청에서 컨테이너 이미지 레지스트리에 직접 액세스하고 미러링 구성을 위한 /etc/containers/registries.conf 읽기, TLS 구성을 위한 이미지 클러스터 리소스 액세스, 노드에서 CA 마운트, Hub & Spoke에서 자체 캐시 유지 관리 등의 작업을 수동으로 처리해야 하는 필요성이 완화됩니다.
  • KMM 및 KMM-hub 운영자는 Red Hat 카탈로그 에서 "모범 사례 충족" 라벨을 지정받았습니다.
  • 필요한 경우 이제 컴퓨팅 노드에 KMM을 설치할 수 있습니다. 이전에는 제어 평면 노드에 워크로드를 배포할 수 없었습니다. 컴퓨팅 노드에 node-role.kubernetes.io/control-plane 또는 node-role.kubernetes.io/master 레이블이 없으므로 커널 모듈 관리 운영자에게 추가 구성이 필요할 수 있습니다. 내부 코드 변경으로 이 문제가 해결되었습니다.

  • 이번 릴리스에서는 NMC 조정기의 하트비트 필터가 업데이트되어 노드에서 다음 이벤트를 필터링합니다.

    • node.spec
    • metadata.labels
    • status.nodeInfo
    • status.conditions[] ( NodeReady 전용) 및 여전히 하트비트 필터링

5.3.2. 주요 기술 변경 사항
링크 복사

  • 이번 릴리스에서는 클러스터의 사전 검증 리소스가 수정되었습니다. 클러스터 업그레이드 및 가능한 커널 업그레이드 후에 노드에 설치될 커널 모듈을 검증하기 위해 사전 검증을 사용할 수 있습니다. 사전 검증에서는 클러스터에서 검증을 시도하거나 검증을 시도한 각 모듈의 상태와 진행 상황을 보고합니다. 자세한 내용은 KMM(커널 모듈 관리) 모듈에 대한 사전 검증을 참조하세요.
  • kmod 이미지를 생성할 때 필요한 것은 .ko 커널 모듈 파일과 cp 바이너리를 모두 포함해야 한다는 것입니다. 이는 이미지 로딩 프로세스 중에 파일을 복사하는 데 필요합니다. 자세한 내용은 kmod 이미지 만들기를 참조하세요.
  • 운영자 성숙도 수준을 나타내는 기능 필드가 기본 설치 에서 원활한 업그레이드 로 변경되었습니다. 기본 설치는 운영자에게 업그레이드 옵션이 없음을 나타냅니다. KMM의 경우에는 원활한 업그레이드가 지원되지 않습니다.

5.3.3. 버그 수정
링크 복사

  • Webhook 배포의 이름이 webhook-server 에서 webhook 으로 변경되었습니다.

    • 원인 : controller-gen 으로 파일을 생성하면 구성할 수 없는 webhook-service 라는 서비스가 생성되었습니다. 그리고 Operator Lifecycle Manager(OLM)와 함께 KMM을 배포하는 경우 OLM은 -service 라는 웹훅에 대한 서비스를 배포합니다.
    • 결과 : 동일한 배포에 대해 두 개의 서비스가 생성되었습니다. 하나는 controller-gen 에서 생성되어 번들 매니페스트에 추가되고, 다른 하나는 OLM에서 생성되었습니다.
    • 수정 : 배포 이름이 webhook 이므로 OLM이 클러스터에서 webhook-service 라는 기존 서비스를 찾도록 합니다.
    • 결과 : 두 번째 서비스가 더 이상 생성되지 않습니다.

  • DTK와 함께 imageRepoSecret 객체를 이미지 스트림으로 사용하면 권한 부여가 필요하다는 오류가 발생합니다.

    • 원인 : 커널 모듈 관리(KMM) 운영자에서 KMM 모듈에 imageRepoSecret 객체를 설정하고 빌드의 결과 컨테이너 이미지가 클러스터의 내부 레지스트리에 저장되도록 정의된 경우, 빌드가 최종 이미지를 푸시하지 못하고 권한 부여가 필요하다는 오류가 발생합니다.
    • 결과 : KMM 연산자가 예상대로 작동하지 않습니다.
    • 수정 사항 : imageRepoSecret 객체가 사용자 정의되면 빌드 프로세스에서 풀 비밀과 푸시 비밀로 모두 사용됩니다. 클러스터의 내부 레지스트리 사용을 지원하려면 해당 레지스트리에 대한 권한 부여 토큰을 imageRepoSecret 개체에 추가해야 합니다. KMM 모듈 네임스페이스의 "빌드" 서비스 계정에서 토큰을 얻을 수 있습니다.
    • 결과 : KMM 연산자가 예상대로 작동합니다.

  • 이미지를 생성하거나 삭제하거나 MCM 모듈을 생성해도 스포크에 모듈이 로드되지 않습니다.

    • 원인 : 허브 앤 스포크 환경에서 레지스트리에 이미지를 생성하거나 삭제할 때, 또는 ManagedClusterModule (MCM)을 생성할 때 스포크 클러스터의 모듈이 로드되지 않습니다.
    • 결과 : 스포크의 모듈이 생성되지 않습니다.
    • 수정 사항 : 허브 앤 스포크 환경에서 캐시 패키지와 이미지 변환을 제거합니다.
    • 결과: MCM 객체가 두 번째로 생성될 때 스포크의 모듈이 생성됩니다.

  • KMM은 클러스터 내 빌드를 수행하는 동안 개인 레지스트리에서 이미지를 가져올 수 없습니다.

    • 원인 : 커널 모듈 관리(KMM) 운영자가 클러스터 내 빌드를 수행하는 동안 개인 레지스트리에서 이미지를 가져올 수 없습니다.
    • 결과 : 빌드 프로세스에 사용되는 개인 레지스트리의 이미지를 가져올 수 없습니다.
    • 수정 사항 : imageRepoSecret 개체 구성이 이제 빌드 프로세스에서도 사용됩니다. 지정된 imageRepoSecret 개체에는 사용 중인 모든 레지스트리가 포함되어야 합니다.
    • 결과: 이제 클러스터 내 빌드를 수행할 때 개인 레지스트리를 사용할 수 있습니다.

  • 컨테이너 이미지를 가져올 수 없는 모듈을 삭제하면 KMM 워커 포드가 고아가 됩니다.

    • 원인 : 컨테이너 이미지를 가져올 수 없는 모듈을 삭제하면 커널 모듈 관리(KMM) 운영자 워커 포드가 분리됩니다.
    • 결과 : 실패한 워커 포드는 클러스터에 남겨지고 가비지로 수집되지 않습니다.
    • 수정 사항 : KMM이 이제 모듈 삭제 시 고아가 된 실패한 포드를 가비지로 수집합니다.
    • 결과: 모듈이 성공적으로 삭제되고, 관련된 모든 고아된 실패한 포드도 삭제됩니다.

  • KMM 운영자는 노드 선택기가 일치하지 않더라도 MIC를 생성하려고 시도합니다.

    • 원인 : 커널 모듈 관리(KMM) 운영자가 노드 선택기가 실제 노드와 일치하지 않더라도 'ModuleImagesConfig'(MIC) 리소스를 만들려고 시도하고 실패합니다.
    • 결과 : KMM 운영자는 어떤 노드도 대상으로 하지 않는 모듈을 조정할 때 오류를 보고합니다.
    • 수정 사항 : MIC 리소스의 이미지 필드가 이제 선택 사항입니다.
    • 결과: KMM 운영자는 이미지가 없더라도 MIC 리소스를 성공적으로 생성할 수 있습니다.

  • 노드 재부팅 시퀀스가 너무 빠른 경우 KMM은 커널 모듈을 다시 로드하지 않습니다.

    • 원인 : 노드 재부팅 시퀀스가 너무 빠른 경우 커널 모듈 관리(KMM) 운영자가 커널 모듈을 다시 로드하지 않습니다. 재부팅 여부는 상태 조건의 타임스탬프가 노드 머신 구성(NMC) 상태의 타임스탬프보다 늦은 경우에 결정됩니다.
    • 결과 : 재부팅이 유예 기간보다 짧은 시간 안에 빠르게 발생하면 노드 상태가 변경되지 않습니다. 노드가 재부팅된 후 KMM은 커널 모듈을 다시 로드하지 않습니다.
    • 수정 사항 : NMC는 조건 상태에 의존하는 대신 Status.NodeInfo.BootID 필드에 의존할 수 있습니다. 이 필드는 서버 노드의 /proc/sys/kernel/random/boot_id 파일을 기반으로 kubelet에 의해 설정되므로 재부팅할 때마다 업데이트됩니다.
    • 결과: 더 정확한 타임스탬프를 통해 커널 모듈 관리(KMM) 운영자는 노드 재부팅 시퀀스 후에 커널 모듈을 다시 로드할 수 있습니다.

  • NMC(노드 머신 구성) 컨트롤러에 대한 노드 하트비트 이벤트를 필터링합니다.

    • 원인 : NMC 컨트롤러가 노드 하트비트로 인한 이벤트로 스팸을 받습니다. 노드 하트비트는 Kubernetes API 서버에 노드가 여전히 연결되어 있고 작동 중임을 알려줍니다.
    • 결과 : 모듈이 없고 NMC도 클러스터에 적용되지 않은 경우에도 스팸으로 인해 지속적인 조정이 발생합니다.
    • 수정 사항 : NMC 컨트롤러가 이제 조정 루프에서 노드의 하트비트를 필터링합니다.
    • 결과: NMC 컨트롤러는 실제 이벤트만 가져오고 노드 하트비트를 필터링합니다.

  • NMC.spec 이나 모듈에 허용 오차가 없더라도 NMC 상태에는 허용 오차 값이 포함되어 있습니다.

    • 원인 : NMC.spec 이나 모듈에 허용 오차가 없는데도 불구하고 노드 머신 구성(NMC) 상태에 허용 오차 값이 포함되어 있습니다.
    • 결과 : 커널 모듈 관리 관련 허용 범위 외의 허용 범위가 상태에 나타날 수 있습니다.
    • 수정 사항 : NMC 상태는 이제 작업자 포드가 아닌 전용 주석에서 허용 범위를 얻습니다.
    • 결과: NMC 상태에는 모듈의 허용 오차만 포함됩니다.

  • KMM Operator 버전 2.4가 제대로 시작되지 않고 \modulebuildsignconfigs\ 리소스를 나열할 수 없습니다.

    • 원인 : Red Hat Konflux를 사용하여 KMM(Kernel Module Management) Operator를 설치한 경우 로그 파일에 오류가 포함되어 있어 제대로 시작되지 않습니다.
    • 결과 : KMM 연산자가 예상대로 작동하지 않습니다.
    • 수정 사항 : 클러스터 서비스 버전(CSV) 파일이 업데이트되어 \modulebuildsignconfigs\ 및 moduleimagesconfig 리소스가 나열됩니다.
    • 결과: KMM 연산자는 예상대로 작동합니다.

  • Red Hat Konflux 빌드에는 Operator 로그에 버전 및 git 커밋 ID가 포함되지 않습니다.

    • 원인 : 커널 모듈 관리(KMM) Operator에서 CPaas(Communications Platform as a Service)를 사용하여 Operator를 빌드한 경우 빌드 로그 파일에 Operator 버전과 git 커밋 ID가 포함되었습니다. 하지만 Red Hat Konflux의 경우 이러한 세부 정보는 로그 파일에 포함되지 않습니다.
    • 결과 : 로그 파일에서 중요한 정보가 누락되었습니다.
    • 수정 사항 : 이 문제를 해결하기 위해 Konflux에 몇 가지 수정 사항이 도입되었습니다.
    • 결과: 이제 KMM Operator 빌드에는 Operator 버전과 git 커밋 ID가 로그 파일에 포함됩니다.

  • KMM 운영자는 오염된 노드가 재부팅된 후 모듈을 로드하지 않습니다.

    • 원인 : 노드 재부팅 시퀀스가 너무 빠른 경우 커널 모듈 관리(KMM) 운영자가 커널 모듈을 다시 로드하지 않습니다. 재부팅 여부는 상태 조건의 타임스탬프가 노드 머신 구성(NMC) 상태의 타임스탬프보다 늦은 경우에 결정됩니다.
    • 결과 : 재부팅이 유예 기간보다 짧은 시간 안에 빠르게 발생하면 노드 상태가 변경되지 않습니다. 노드가 재부팅된 후 KMM은 커널 모듈을 다시 로드하지 않습니다.
    • 수정 사항 : NMC는 조건 상태에 의존하는 대신 Status.NodeInfo.BootID 필드에 의존할 수 있습니다. 이 필드는 서버 노드의 /proc/sys/kernel/random/boot_id 파일을 기반으로 kubelet에 의해 설정되므로 재부팅할 때마다 업데이트됩니다.
    • 결과: 더 정확한 타임스탬프를 통해 커널 모듈 관리(KMM) 운영자는 노드 재부팅 시퀀스 후에 커널 모듈을 다시 로드할 수 있습니다.

  • 클러스터 내 빌드를 사용하는 모듈을 다시 배포하면 ImagePullBackOff 정책으로 인해 실패합니다.

    • 원인 : 커널 모듈 관리(KMM) 운영자에서 풀러 포드와 워커 포드의 이미지 풀 정책이 다릅니다.
    • 결과 : 이미지는 실제로 존재하지 않는데도 존재하는 것으로 간주될 수 있습니다.
    • 수정 : 풀 포드의 이미지 풀 정책을 KMM 모듈에 정의된 풀 정책과 동일하게 만듭니다. 이 정책은 워커 포드에서 사용하는 정책과 동일합니다.
    • 결과: MIC는 작업자 포드가 이미지에 액세스하는 것과 같은 방식으로 이미지 상태를 나타냅니다.

  • MIC 컨트롤러는 풀포드를 하나만 생성해야 하는데 두 개를 생성합니다.

    • 원인 : 커널 모듈 관리(KMM) 운영자에서 ModuleImagesConfig (MIC) 컨트롤러가 동일한 이미지에 대해 여러 개의 풀 포드를 생성할 수 있습니다.
    • 결과 : 리소스가 적절하게 또는 의도한 대로 사용되지 않습니다.
    • 수정 사항 : CreateOrPatch MIC API는 대상 노드를 검토하고 해당 노드의 이미지를 슬라이스에 추가하여 입력을 생성하므로 ImageSpecs 슬라이스를 수신하므로 중복된 ImageSpecs 는 이제 필터링됩니다.
    • 결과: KMM 연산자는 예상대로 작동합니다.

  • 설명서의 job.dcDelay 예제에서는 0 대신 0s를 지정해야 합니다.

    • 원인 : 커널 모듈 관리(KMM) 운영자의 기본 job.gcDelay 기간 필드는 0초이지만 설명서에는 값이 0 이라고 나와 있습니다.
    • 결과 : 60초 또는 1m 대신 사용자 지정 값 60을 입력하면 잘못된 입력 유형으로 인해 오류가 발생할 수 있습니다.
    • 수정 사항 : 설명서의 job.gcDelay 필드가 기본값 0 으로 업데이트되었습니다.
    • 결과: 사용자가 혼란스러워할 가능성이 줄어듭니다.

  • MIC와 MBSC CRD가 없기 때문에 KMM Operator Hub 환경이 작동하지 않습니다.

    • 원인 : KMM(커널 모듈 관리) 운영자 허브 환경은 api-hub/ 디렉토리를 기반으로 사용자 정의 리소스 정의(CRD) 파일만 생성합니다. 결과적으로 여기에는 KMM Operator Hub 환경에 필요한 ModuleImagesConfig (MIC) 리소스 및 Managed Kubernetes Service(MBSC)와 같은 일부 CRD가 포함되지 않습니다.
    • 결과 : KMM 운영자 허브 환경은 클러스터에 존재하지 않는 CRD를 조정하는 컨트롤러를 시작하려고 하기 때문에 작동할 수 없습니다.
    • 수정 사항 : 이 수정 사항은 모든 CRD 파일을 config/crd-hub/bases 디렉토리에 생성하지만, 실제로 필요한 리소스만 클러스터에 적용합니다.
    • 결과: KMM Operator 허브 환경이 예상대로 작동합니다.

  • 리소스에 종료자가 설정되지 않으면 KMM OperatorHub 환경을 빌드할 수 없습니다.

    • 원인 : 커널 모듈 관리(KMM) 운영자가 ManagedClusterModule 컨트롤러 빌드에 실패하여 오류를 표시합니다. 이는 KMM OperatorHub 환경에 대한 ModuleImagesConfig (MIC) 리소스 종료자와 역할 기반 작업 제어(RBAC) 권한이 없기 때문에 발생합니다.
    • 결과 : KMM OperatorHub 환경에서 이미지를 빌드할 수 없습니다.
    • 수정 사항 : RBAC 권한이 업데이트되어 MIC 리소스의 종료자를 업데이트할 수 있게 되었고, 그에 따라 적절한 규칙이 생성되었습니다.
    • 결과: KMM OperatorHub 환경은 ManagedClusterModule 컨트롤러를 사용하여 오류 없이 이미지를 빌드합니다.

  • kernelVersion: tesdt가 있는 PreflightValidationOCP 사용자 정의 리소스로 인해 KMM 운영자가 패닉 상태에 빠지게 됩니다.

    • 원인 : kernelVersion 플래그를 tesdt 로 설정하여 PreflightValidationOCP 사용자 정의 리소스(CR)를 생성하면 커널 모듈 관리(KMM) 운영자가 패닉 런타임 오류를 생성합니다.
    • 결과 : 잘못된 커널 버전을 입력하면 KMM 운영자가 당황하게 됩니다.
    • 수정 사항 : 특정 이벤트가 발생할 때 한 애플리케이션이 다른 애플리케이션에 실시간 데이터를 자동으로 전송하는 방법인 웹훅이 이제 PreflightValidationOCP CR에 추가되었습니다.
    • 결과: 잘못된 커널 버전을 사용하는 PreflightValidationOCP CR은 더 이상 클러스터에 적용될 수 없으므로 Operator가 패닉 런타임 오류를 생성하는 것을 방지합니다.

  • 클러스터의 kernelVersion 플래그와 다른 kernelVersion 플래그를 사용하는 PreFflightValidationOCP 사용자 정의 리소스는 작동하지 않습니다.

    • 원인 : 클러스터의 kernelVersion 플래그와 다른 kernelVersion 플래그를 사용하여 PreflightValidationOCP 사용자 정의 리소스(CR)를 생성하는 것이 작동하지 않습니다.
    • 결과 : 커널 모듈 관리(KMM) 운영자가 새 커널 버전에 대한 드라이버 툴킷(DTK) 입력 이미지를 찾을 수 없습니다.
    • 수정 : PreflightValidationOCP CR을 사용하고 CR에서 dtkImage 필드를 명시적으로 설정해야 합니다.
    • 결과: kernelVersion 및 dtkImage 필드를 사용하여 이 기능은 대상 OpenShift Container Platform 버전에 대해 설치된 모듈을 빌드할 수 있습니다.

  • KMM Operator 버전 2.4 설명서가 PreflightValidationOCP 정보로 업데이트되었습니다.

    • 원인 : 이전에는 PreflightValidationOCP CR을 생성할 때 릴리스 이미지를 제공해야 했습니다. 이제 이것이 변경되었으며 dtkImage 필드의 kernelVersion을 설정해야 합니다.
    • 결과 : 문서가 오래되어 업데이트가 필요했습니다.
    • 수정 사항 : 새로운 지원 세부 정보로 설명서가 업데이트되었습니다.
    • 결과: KMM 프리플라이트 기능이 예상대로 문서화되었습니다.

5.3.4. 확인된 문제
링크 복사

  • 모듈이 언로드 되면 ModuleUnloaded 이벤트가 나타나지 않습니다.

    • 원인 : 모듈이 로드 ( ModuleLoad 이벤트 생성 사용)되거나 언로드(ModuleUnloaded 이벤트 생성 사용 )될 때 이벤트가 나타나지 않을 수 있습니다. 이는 커널 모듈을 빠른 연속으로 로드하고 언로드할 때 발생합니다.
    • 결과 : ModuleLoad 및 ModuleUnloaded 이벤트가 OpenShift Container Platform에 나타나지 않을 수 있습니다.
    • 수정 사항 : 이러한 잠재적 동작에 대한 경고 메커니즘을 도입하고 모듈 작업 시 인식을 높입니다.
    • 결과: 아직 나오지 않았습니다.

5.4. 커널 모듈 관리 운영자 2.4.1 릴리스 노트
링크 복사

5.4.1. 확인된 문제
링크 복사

KMM-hub 버전 2.3.0 이하를 실행 중이고 KMM을 실행하지 않는 경우 KMM-hub 2.4.0으로 업그레이드하는 것은 안정적이지 않습니다. 대신 KMM-hub 2.4.1로 업그레이드해야 합니다. KMM은 이 문제의 영향을 받지 않습니다. 자세한 내용은 RHEA-2025:10778 - 제품 개선 권고를 참조하세요.

Legal Notice
링크 복사

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat