4.3. 커널 모듈 배포
각 모듈
리소스에 대해 커널 모듈 관리(KMM)에서 여러 DaemonSet
리소스를 생성할 수 있습니다.
-
클러스터에서 실행되는 호환 커널 버전당 하나의 ModuleLoader
DaemonSet
. -
구성된 경우 하나의 장치 플러그인
DaemonSet
.
모듈 로더 데몬 세트 리소스는 ModuleLoader 이미지를 실행하여 커널 모듈을 로드합니다. 모듈 로더 이미지는 .ko
파일과 modprobe
및 sleep
바이너리가 모두 포함된 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
리소스의 조정 루프는 다음 단계를 실행합니다.
-
.spec.selector
와 일치하는 모든 노드를 나열합니다. - 해당 노드에서 실행 중인 모든 커널 버전 세트를 빌드합니다.
각 커널 버전에 대해 다음을 수행합니다.
-
.spec.moduleLoader.container.kernelMappings
를 통과하여 적절한 컨테이너 이미지 이름을 찾습니다. 커널 매핑에빌드
또는서명이
정의되어 있고 컨테이너 이미지가 아직 없는 경우 필요에 따라 빌드, 서명 작업 또는 둘 다 실행합니다. - 이전 단계에서 결정된 컨테이너 이미지를 사용하여 모듈 로더 데몬 세트를 생성합니다.
-
.spec.devicePlugin
이 정의된 경우.spec.devicePlugin.container
에 지정된 구성을 사용하여 장치 플러그인 데몬 세트를 생성합니다.
-
다음과 같이
가비지 수집
을 실행합니다.- 클러스터의 노드에서 실행하지 않는 커널 버전을 대상으로 하는 기존 데몬 세트 리소스입니다.
- 성공적인 빌드 작업.
- 성공적인 서명 작업.
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를 사용하도록 수동으로 활성화하지 않는 한모듈
리소스는 권한있는
워크로드를 실행할 수 없습니다.
-
Operator의 네임 스페이스(기본적으로
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를 사용하여 DockerfileFROM
명령에서 이미지를 가져올 수 있습니다. - 11
- 선택 사항: 이 매개변수를 사용하지 마십시오.
true
로 설정하면 빌드에서 일반 HTTP를 사용하여 DockerfileFROM
명령에서 이미지를 가져올 때 모든 TLS 서버 인증서 검증을 건너뜁니다. - 12
- 필수 항목입니다.
- 13
- 필수: 'cert' 키가 있는 공용 secureboot 키를 보유한 시크릿입니다.
- 14
- 필수: 키가 'key'인 개인 secureboot 키를 보유한 시크릿입니다.
- 15
- 선택 사항: 이 매개변수를 사용하지 마십시오.
true
로 설정하면 KMM이 일반 HTTP를 사용하여 컨테이너 이미지가 이미 존재하는지 확인할 수 있습니다. - 16
- 선택 사항: 이 매개변수를 사용하지 마십시오.
true
로 설정하면 KMM은 컨테이너 이미지가 이미 존재하는지 확인할 때 모든 TLS 서버 인증서 검증을 건너뜁니다. - 17
- 선택 사항:
- 18
- 선택 사항:
- 19
- 필수: 장치 플러그인 섹션이 있는 경우
- 20
- 선택 사항:
- 21
- 선택 사항:
- 22
- 선택 사항:
- 23
- 선택 사항: 모듈 로더 및 장치 플러그인 이미지를 가져오는 데 사용됩니다.