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

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에 나타나지 않을 수 있습니다.
    • 수정 사항 : 이러한 잠재적 동작에 대한 경고 메커니즘을 도입하고 모듈 작업 시 인식을 높입니다.
    • 결과: 아직 나오지 않았습니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat