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

5.3. Kernel Module Management Operator 2.4 릴리스 노트

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

  • 이번 릴리스에서는 out-of-tree 커널 드라이버를 로드하지 않고 대신 in-tree 드라이버를 사용하고 장치 플러그인만 실행하도록 KMM(커널 모듈 관리) 모듈을 구성하는 옵션이 있습니다. 자세한 내용은 장치 플러그인에서 in-tree 모듈 사용을 참조하십시오.

  • 이번 릴리스에서는 cluster 및 KMM Operator를 업그레이드하고 KMM의 재배포 후 KMM 구성이 지속됩니다.

    이전 릴리스에서는 클러스터 또는 KMM 업그레이드 또는 KMM을 재배포하는 펌웨어 경로와 같은 기본 구성이 아닌 구성을 업그레이드하는 경우 KMM을 재구성할 필요가 발생할 수 있습니다. 이번 릴리스에서는 이러한 작업과 관계없이 KMM 구성이 영구적으로 유지됩니다.

    자세한 내용은 Kernel Module Management Operator 구성을 참조하십시오.

  • GPU Operator 공급 업체가 코드에서 KMM 기능을 복제할 필요가 없지만 KMM을 사용하는 대신 KMM이 KMM에 추가되었습니다. 이 변경으로 Operator의 코드 크기, 테스트 및 안정성이 크게 향상됩니다.
  • 이번 릴리스에서는 KMM에서 더 이상 HTTP(S) 직접 요청을 사용하여 kmod 이미지가 존재하는지 확인합니다. 대신 CRI-O는 이미지를 확인하는 데 내부적으로 사용됩니다. 이렇게 하면 HTTP(S) 요청에서 직접 컨테이너 이미지 레지스트리에 액세스하고 미러링 구성을 위해 /etc/containers/registries.conf 를 읽고, TLS 구성을 위한 이미지 클러스터에 액세스하고 노드에서 CA를 마운트하고 Hub & Spoke에서 자체 캐시를 유지 관리하는 것과 같은 작업을 수동으로 처리할 필요가 완화됩니다.
  • KMM 및 KMM-hub Operator에는 Red Hat 카탈로그 의 "Meets Best Practices" 레이블이 할당되어 있습니다.
  • 필요한 경우 컴퓨팅 노드에 KMM을 설치할 수 있습니다. 이전에는 컨트롤 플레인 노드에 워크로드를 배포할 수 없었습니다. 컴퓨팅 노드에 node-role.kubernetes.io/control-plane 또는 node-role.kubernetes.io/master 레이블이 없으므로 Kernel Module Management Operator에 추가 구성이 필요할 수 있습니다. 내부 코드 변경으로 이 문제가 해결되었습니다.

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

    • node.spec
    • metadata.labels
    • status.nodeInfo
    • status.conditions[] (NodeReady 만 해당) 및 하트비트 필터링

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

  • 이번 릴리스에서는 클러스터의 preflight 검증 리소스가 수정되었습니다. preflight 검증을 사용하여 클러스터 업그레이드 및 커널 업그레이드 후 노드에 커널 모듈을 설치할 수 있는지 확인할 수 있습니다. preflight 검증은 클러스터에서 시도하거나 검증하려고 시도한 각 모듈의 상태 및 진행 상황을 보고합니다. 자세한 내용은 KMM(커널 모듈 관리) 모듈에 대한 Preflight 검증 에서 참조하십시오.
  • kmod 이미지를 생성할 때 요구 사항은 .ko 커널 모듈 파일과 cp 바이너리가 포함되어 있어야 하므로 이미지 로드 프로세스 중에 파일을 복사해야 합니다. 자세한 내용은 kmod 이미지 생성을 참조하십시오.
  • Operator 완성 수준을 나타내는 capabilities 필드가 Basic Install 에서 Seamless 업그레이드 로 변경되었습니다. 기본 설치 는 Operator에 업그레이드 옵션이 없음을 나타냅니다. 이는 원활한 업그레이드가 지원되는 KMM의 경우는 아닙니다.

5.3.3. 버그 수정
링크 복사

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

    • cause: controller-gen 을 사용하여 파일을 생성하면 구성할 수 없는 webhook-service 서비스가 생성되었습니다. 또한 OLM(Operator Lifecycle Manager)을 사용하여 KMM을 배포할 때 OLM은 -service 라는 웹 후크에 대한 서비스를 배포합니다.
    • 결과: 동일한 배포를 위해 두 서비스가 생성되었습니다. 하나는 controller-gen 에 의해 생성되고 번들 매니페스트 및 OLM에서 생성한 다른 번들 매니페스트에 추가되었습니다.
    • 수정: 배포가 웹 후크라고 되므로 OLM에서 클러스터에서 webhook -service 라는 기존 서비스를 찾도록 합니다.
    • 결과: 두 번째 서비스가 더 이상 생성되지 않습니다.

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

    • 원인:KMM(커널 모듈 관리) Operator에서 KMM 모듈에 imageRepoSecret 오브젝트를 설정하고 빌드의 결과 컨테이너 이미지가 클러스터의 내부 레지스트리에 저장되도록 정의되면 빌드가 최종 이미지를 푸시하고 인증 필요한 오류를 생성합니다.
    • 결과: KMM Operator가 예상대로 작동하지 않습니다.
    • 수정: imageRepoSecret 오브젝트가 사용자 정의되면 빌드 프로세스에서 가져오기 및 푸시 시크릿으로 사용됩니다. 클러스터의 내부 레지스트리 사용을 지원하려면 해당 레지스트리의 권한 부여 토큰을 imageRepoSecret 오브젝트에 추가해야 합니다. KMM 모듈 네임스페이스의 "build" 서비스 계정에서 토큰을 가져올 수 있습니다.
    • 결과: KMM Operator가 예상대로 작동합니다.

  • 이미지를 생성하거나 삭제하거나 MCM 모듈을 생성하는 경우 이 모듈을 로드하지 않습니다.

    • Hub 및 spoke 환경에서 레지스트리에서 이미지를 생성하거나 삭제할 때 MCM( ManagedClusterModule )을 생성할 때 spoke 클러스터에 모듈이 로드되지 않습니다.
    • 결과: spoke의 모듈이 생성되지 않습니다.
    • 수정: hub 및 spoke 환경에서 캐시 패키지 및 이미지 변환을 제거합니다.
    • 결과: MCM 오브젝트가 두 번째로 생성되는 경우 spoke의 모듈이 생성됩니다.

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

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

  • KMM 작업자 Pod는 가져올 수 없는 컨테이너 이미지로 모듈을 삭제할 때 분리됩니다.

    • 원인: KMM(커널 모듈 관리) Operator 작업자 Pod는 가져올 수 없는 컨테이너 이미지로 모듈을 삭제할 때 분리됩니다.
    • 결과: 작업자 Pod가 클러스터에 남아 있고 가비지를 위해 수집되지 않습니다.
    • 수정: KMM은 이제 가비지에 대한 모듈 삭제 시 고립된 실패한 Pod를 수집합니다.
    • 결과: 모듈이 성공적으로 삭제되고 고립된 모든 실패한 Pod도 삭제됩니다.

  • KMM Operator는 노드 선택기가 일치하지 않는 경우에도 MIC를 생성하려고 합니다.

    • 원인: KMM(커널 모듈 관리) Operator는 노드 선택기가 실제 노드와 일치하지 않는 경우에도 'ModuleImagesConfig'(MIC) 리소스를 생성하려고 합니다.
    • 결과: KMM Operator에서 노드를 대상으로 하지 않는 모듈을 조정할 때 오류를 보고합니다.
    • fix: MIC 리소스의 Images 필드는 선택 사항입니다.
    • 결과: KMM Operator는 이미지가 없는 경우에도 MIC 리소스를 생성할 수 있습니다.

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

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

  • Node Machine Configuration(NMC) 컨트롤러에 대한 노드 하트비트 이벤트를 필터링합니다.

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

  • NMC 상태에는 NMC.spec 또는 모듈에 허용 오차 값이 없는 경우에도 허용 오차 값이 포함되어 있습니다.

    • cause:NMC(Node Machine Configuration) 상태에는 NMC.spec 또는 모듈에 허용 오차 값이 없는 경우에도 허용 오차 값이 포함되어 있습니다.
    • 결과적으로 커널 모듈 관리 특정 허용 오차 이외의 허용 오차가 상태에 표시될 수 있습니다.
    • 수정: NMC 상태에 따라 작업자 Pod가 아닌 전용 주석에서 허용 오차가 부여됩니다.
    • 결과: NMC 상태에는 모듈의 허용 오차만 포함됩니다.

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

    • 원인:KMM(커널 모듈 관리) Operator에서 Operator가 Red Hat Konflux를 사용하여 설치되면 로그 파일에 오류가 포함되어 있기 때문에 제대로 시작되지 않습니다.
    • 결과: KMM Operator가 예상대로 작동하지 않습니다.
    • 수정: CSV(Cluster Service Version) 파일이 업데이트되어 \modulebuildsignconfigs\ 및 moduleimagesconfig 리소스가 나열됩니다.
    • 결과: KMM Operator가 예상대로 작동합니다.

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

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

  • KMM Operator는 테인트를 사용하여 노드를 재부팅한 후 모듈을 로드하지 않습니다.

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

  • 클러스터 내 빌드를 사용하는 모듈을 재배포하면 ImagePullBackOff 정책과 함께 실패합니다.

    • cause:KMM(커널 모듈 관리) Operator에서는 puller Pod 및 작업자 Pod에 대한 이미지 가져오기 정책이 다릅니다.
    • 결과: 실제로 이미지는 존재하지 않는 동안 존재하는 것으로 간주될 수 있습니다.
    • 수정: 작업자 Pod에서 사용하는 정책과 동일한 정책이므로 가져오기 Pod의 이미지 가져오기 정책을 KMM 모듈에 정의된 가져오기 정책과 동일하게 설정합니다.
    • 결과: MIC는 작업자 Pod가 액세스하는 방식과 동일한 방식으로 이미지 상태를 나타냅니다.

  • MIC 컨트롤러는 하나만 생성해야 할 때 두 개의 pull-pod를 생성합니다.

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

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

    • 원인: KMM(커널 모듈 관리) Operator 기본 job.gcDelay duration 필드는 0s 이지만 문서에는 값이 0 으로 표시됩니다.
    • 결과: 60 s 또는 1m 대신 사용자 지정 값을 입력하면 잘못된 입력 유형으로 인해 오류가 발생할 수 있습니다.
    • 수정: 문서의 job.gcDelay 필드는 기본값 0s 로 업데이트됩니다.
    • 결과: 사용자가 혼란스러울 가능성이 낮습니다.

  • MIC 및 MBSC CRD가 누락되어 KMM Operator Hub 환경이 작동하지 않습니다.

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

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

    • 원인:KMM(커널 모듈 관리) Operator에 ManagedClusterModule 컨트롤러가 빌드되지 않아 오류가 표시됩니다. 이는 KMM OperatorHub 환경에 대해 누락된 ModuleImagesConfig (MIC) 리소스 종료자 및 RBAC(역할 기반 작업 제어) 권한 때문입니다.
    • 결과: KMM OperatorHub 환경은 이미지를 빌드할 수 없습니다.
    • 수정: MIC 리소스에서 종료자를 업데이트할 수 있도록 RBAC 권한이 업데이트되고 적절한 규칙이 생성됩니다.
    • 결과: KMM OperatorHub 환경은 ManagedClusterModule 컨트롤러와 함께 오류 없이 이미지를 빌드합니다.

  • kernelVersion: tesdt 가 있는 PreflightValidationOCP 사용자 정의 리소스로 인해 KMM Operator에 패닉이 발생합니다.

    • 원인: PreflightValidationOCP CR(사용자 정의 리소스)을 생성하여 tesdt 로 설정된 kernelVersion 플래그를 사용하면 KMM(커널 모듈 관리) Operator가 패닉 런타임 오류를 생성합니다.
    • 결과: 유효하지 않은 커널 버전을 입력하면 KMM Operator가 패닉 상태가 됩니다.
    • 수정: A webhook - 특정 이벤트가 발생할 때 다른 애플리케이션에 실시간 데이터를 자동으로 보내는 방법 - 이제 PreflightValidationOCP CR에 추가됩니다.
    • 결과: 유효하지 않은 커널 버전이 있는 PreflightValidationOCP CR을 더 이상 클러스터에 적용할 수 없으므로 Operator에서 패닉 런타임 오류가 발생하지 않습니다.

  • 클러스터 중 하나가 작동하지 않는 kernelVersion 플래그가 있는 PreFflightValidationOCP 사용자 정의 리소스입니다.

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

  • KMM Operator 버전 2.4 설명서는 PreflightValidationOCP 정보로 업데이트됩니다.

    • 원인: 이전 버전에서는 PreflightValidationOCP CR을 생성할 때 release-image를 제공해야 했습니다. 이제 변경되었으며 kernelVersion 을 dtkImage 필드를 설정해야 합니다.
    • 그 결과: 문서가 오래되었으며 업데이트가 필요했습니다.
    • 수정: 문서가 새로운 지원 세부 정보로 업데이트됩니다.
    • 결과: KMM preflight 기능이 예상대로 문서화되어 있습니다.

5.3.4. 확인된 문제
링크 복사

  • 모듈이 로드되지 않은 경우 Module Unloaded 이벤트가 표시되지 않습니다.

    • 원인: 모듈이 로드된 경우(module Load 이벤트 생성) 또는 Unloaded '를 사용하여 'ModuleUnloaded 이벤트 생성 사용) 이벤트가 나타나지 않을 수 있습니다. 이 작업은 빠른 연속으로 커널 모듈을 로드하고 언로드할 때 발생합니다.
    • 결과: ModuleLoad 및 ModuleUnloaded 이벤트가 OpenShift Container Platform에 표시되지 않을 수 있습니다.
    • 수정: 이러한 잠재적인 동작 및 모듈을 사용할 때 인식에 대한 경고 메커니즘을 소개합니다.
    • 결과: 아직 사용할 수 없습니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat