검색

4.3. 커널 모듈 배포

download PDF

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

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

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

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

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

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

4.3.1. 모듈 사용자 정의 리소스 정의

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

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

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

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

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

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

4.3.2. 보안 및 권한

중요

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

4.3.2.1. ServiceAccounts 및 SecurityContextConstraints

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

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

  • .spec.moduleLoader.serviceAccountName 또는 .spec.devicePlugin.serviceAccountName 필드가 설정된 경우 항상 사용됩니다.
  • 해당 필드가 설정되지 않은 경우 다음을 수행합니다.

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

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

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

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

$ oc adm policy add-scc-to-user privileged -z "${serviceAccountName}" [ -n "${namespace}" ]

4.3.2.2. Pod 보안 표준

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

4.3.3. 모듈 CR의 예

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

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}"
          build:
            buildArgs:  8
              - name: ARG_NAME
                value: <some_value>
            secrets:
              - name: <some_kubernetes_secret>  9
            baseImageRegistryTLS: 10
              insecure: false
              insecureSkipTLSVerify: false 11
            dockerfileConfigMap:  12
              name: <my_kmod_dockerfile>
          sign:
            certSecret:
              name: <cert_secret>  13
            keySecret:
              name: <key_secret>  14
            filesToSign:
              - /opt/lib/modules/${KERNEL_FULL_VERSION}/<my_kmod>.ko
          registryTLS: 15
            insecure: false 16
            insecureSkipTLSVerify: false
    serviceAccountName: <sa_module_loader>  17
  devicePlugin:  18
    container:
      image: some.registry/org/device-plugin:latest  19
      env:
        - name: MY_DEVICE_PLUGIN_ENV_VAR
          value: SOME_VALUE
      volumeMounts:  20
        - mountPath: /some/mountPath
          name: <device_plugin_volume>
    volumes:  21
      - name: <device_plugin_volume>
        configMap:
          name: <some_configmap>
    serviceAccountName: <sa_device_plugin> 22
  imageRepoSecret:  23
    name: <secret_name>
  selector:
    node-role.kubernetes.io/worker: ""
1 1 1
필수 항목입니다.
2
선택 사항:
3
선택 사항: /firmware/* 를 노드의 /var/lib/firmware/ 로 복사합니다.
4
선택 사항:
5
하나 이상의 커널 항목이 필요합니다.
6
정규 표현식과 일치하는 커널을 실행하는 각 노드의 KMM은 ${KERNEL_FULL_VERSION} 을 사용하여 containerImage 에 지정된 이미지를 실행하는 DaemonSet 리소스를 커널 버전으로 대체합니다.
7
다른 커널의 경우 my-kmod ConfigMap의 Dockerfile을 사용하여 이미지를 빌드합니다.
8
선택 사항:
9
선택 사항: some-kubernetes-secret 의 값은 /run/secrets/some-kubernetes-secret 의 빌드 환경에서 가져올 수 있습니다.
10
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 빌드에서 일반 HTTP를 사용하여 Dockerfile FROM 명령에서 이미지를 가져올 수 있습니다.
11
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 빌드에서 일반 HTTP를 사용하여 Dockerfile FROM 명령에서 이미지를 가져올 때 모든 TLS 서버 인증서 검증을 건너뜁니다.
12
필수 항목입니다.
13
필수: 'cert' 키가 있는 공용 secureboot 키를 보유한 시크릿입니다.
14
필수: 키가 'key'인 개인 secureboot 키를 보유한 시크릿입니다.
15
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 KMM이 일반 HTTP를 사용하여 컨테이너 이미지가 이미 존재하는지 확인할 수 있습니다.
16
선택 사항: 이 매개변수를 사용하지 마십시오. true 로 설정하면 KMM은 컨테이너 이미지가 이미 존재하는지 확인할 때 모든 TLS 서버 인증서 검증을 건너뜁니다.
17
선택 사항:
18
선택 사항:
19
필수: 장치 플러그인 섹션이 있는 경우
20
선택 사항:
21
선택 사항:
22
선택 사항:
23
선택 사항: 모듈 로더 및 장치 플러그인 이미지를 가져오는 데 사용됩니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.