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

4.4. 커널 모듈 배포

각 Module 리소스에 대해 커널 모듈 관리(KMM)에서 여러 DaemonSet 리소스를 생성할 수 있습니다.

  • 클러스터에서 실행되는 호환 커널 버전당 하나의 ModuleLoader DaemonSet.
  • 구성된 경우 하나의 장치 플러그인 DaemonSet.

모듈 로더 데몬 세트 리소스는 ModuleLoader 이미지를 실행하여 커널 모듈을 로드합니다. 모듈 로더 이미지는 .ko 파일과 modprobe 및 sleep 바이너리가 모두 포함된 OCI 이미지입니다.

모듈 로더 Pod가 생성되면 Pod는 modprobe 를 실행하여 지정된 모듈을 커널에 삽입합니다. 그런 다음 종료될 때까지 유휴 상태로 전환됩니다. 이 경우 ExecPreStop 후크는 modprobe -r 을 실행하여 커널 모듈을 언로드합니다.

.spec.devicePlugin 특성이 Module 리소스에서 구성된 경우 KMM은 클러스터에 장치 플러그인 데몬 세트를 생성합니다. 해당 데몬 세트 대상:

  • Module 리소스의 .spec.selector 와 일치하는 노드입니다.
  • 커널 모듈이 로드된 노드(모듈 로더 Pod가 Ready 상태에 있음).

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

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

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

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

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

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

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

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

    1. 클러스터의 노드에서 실행하지 않는 커널 버전을 대상으로 하는 기존 데몬 세트 리소스입니다.
    2. 성공적인 빌드 작업.
    3. 성공적인 서명 작업.

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

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

modulesLoadingOrder 필드를 사용하여 CRD(Module Custom Resource Definition)에서 소프트 종속성을 선언하여 이러한 상황을 해결할 수 있습니다. 

# ...
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

위의 구성에서 다음을 수행합니다.

  • 로드 순서는 mod_b, mod_a입니다.
  • 언로드 순서는 mod_a, mod_b입니다.
참고

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

4.4.3. 보안 및 권한
링크 복사

중요

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

4.4.3.1. ServiceAccounts 및 SecurityContextConstraints
링크 복사

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

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

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

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

    • Operator의 네임 스페이스(기본적으로openshift-kmm )에서 Module 리소스가 생성되는 경우 KMM은 기본 강력한 ServiceAccounts 를 사용하여 데몬 세트를 실행합니다.
    • Module 리소스가 다른 네임스페이스에서 생성되는 경우 KMM은 네임스페이스의 default ServiceAccount 로 데몬 세트를 실행합니다. 권한 있는 SCC를 사용하도록 수동으로 활성화하지 않는 한 Module 리소스는 privileged 워크로드를 실행할 수 없습니다.
중요

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

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

모든 ServiceAccount 가 privileged SCC를 사용하도록 허용하여 모듈 로더 또는 장치 플러그인 Pod를 실행하려면 다음 명령을 사용합니다. 

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

4.4.3.2. Pod 보안 표준
링크 복사

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

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat