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-kmodConfigMap의 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
- 선택 사항: 모듈 로더 및 장치 플러그인 이미지를 가져오는 데 사용됩니다.