4.10. kmod 이미지 생성
KMM(커널 모듈 관리)은 .ko 파일을 포함하는 표준 OCI 이미지인 특수 목적의 kmod 이미지와 함께 작동합니다. .ko 파일의 위치는 다음 패턴과 일치해야 합니다: <prefix>/lib/modules/[kernel-version]/ .
.ko 파일을 사용할 때 다음 사항을 염두에 두십시오.
-
대부분의 경우
<prefix>는/opt와 같아야 합니다. 이는모듈CRD의 기본값입니다. -
kernel-version은비어 있을 수 없으며 커널 모듈이 빌드된 커널 버전과 동일해야 합니다.
.ko 파일 외에도 kmod 이미지에는 cp 바이너리도 있어야 합니다. .ko 파일은 이 이미지에서 Operator가 생성한 이미지 로더 워커 포드로 복사되기 때문입니다. 이는 최소 요구 사항이며 이미지에 다른 바이너리 도구가 필요하지 않습니다.
4.10.1. depmod 실행 링크 복사링크가 클립보드에 복사되었습니다!
빌드 프로세스가 끝날 때 depmod를 실행하여 modules.dep 및 .map 파일을 생성하는 것이 좋습니다. 이 기능은 kmod 이미지에 여러 개의 커널 모듈이 포함되어 있고, 모듈 중 하나가 다른 모듈에 종속되어 있는 경우에 특히 유용합니다.
kernel-devel 패키지를 다운로드하려면 Red Hat 서브스크립션이 있어야 합니다.
프로세스
다음 명령을 실행하여 특정 커널 버전에 대한
modules.dep및.map파일을 생성합니다.$ depmod -b /opt ${KERNEL_FULL_VERSION}+`.Dockerfile 예
OpenShift Container Platform에서 이미지를 빌드하는 경우 DTK(Driver Toolkit)를 사용하는 것을 고려하세요.
자세한 내용은 권한이 부여된 빌드 사용을 참조하십시오.
apiVersion: v1 kind: ConfigMap metadata: name: kmm-ci-dockerfile data: dockerfile: | ARG DTK_AUTO FROM ${DTK_AUTO} as builder ARG KERNEL_FULL_VERSION WORKDIR /usr/src RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/kernel-module-management.git"] WORKDIR /usr/src/kernel-module-management/ci/kmm-kmod RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_FULL_VERSION}/build make all FROM registry.redhat.io/ubi9/ubi-minimal ARG KERNEL_FULL_VERSION RUN microdnf install kmod COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ RUN depmod -b /opt ${KERNEL_FULL_VERSION}
4.10.2. 클러스터의 빌드 링크 복사링크가 클립보드에 복사되었습니다!
KMM은 클러스터에 kmod 이미지를 빌드할 수 있습니다. 다음 지침을 따르십시오.
-
커널 매핑의
build섹션을 사용하여 빌드 지침을 제공합니다. -
컨테이너 이미지의
Dockerfile을 dockerfile 키 아래의ConfigMap리소스에 복사합니다. -
ConfigMap이Module과 동일한 네임스페이스에 있는지 확인합니다.
KMM은 containerImage 필드에 지정된 이미지 이름이 있는지 확인합니다. 이 경우 빌드를 건너뜁니다.
그러지 않으면 KMM에서 Build 리소스를 생성하여 이미지를 빌드합니다. 이미지가 빌드된 후 KMM은 Module 조정을 진행합니다. 다음 예제를 참조하십시오.
# ...
- regexp: '^.+$'
containerImage: "some.registry/org/<my_kmod>:${KERNEL_FULL_VERSION}"
build:
buildArgs:
- name: ARG_NAME
value: <some_value>
secrets:
- name: <some_kubernetes_secret>
baseImageRegistryTLS:
insecure: false
insecureSkipTLSVerify: false
dockerfileConfigMap:
name: <my_kmod_dockerfile>
registryTLS:
insecure: false
insecureSkipTLSVerify: false
- 1
- 선택 사항:
- 2
- 선택 사항:
- 3
/run/secrets/some-kubernetes-secret으로 빌드 Pod에 마운트됩니다.- 4
- 선택 사항: 이 매개변수를 사용하지 마십시오.
true로 설정하면 빌드가 일반 HTTP를 사용하여 DockerfileFROM명령에서 이미지를 가져올 수 있습니다. - 5
- 선택 사항: 이 매개변수를 사용하지 마십시오.
true로 설정하면 빌드에서 일반 HTTP를 사용하여 DockerfileFROM명령에서 이미지를 가져올 때 모든 TLS 서버 인증서 검증을 건너뜁니다. - 6
- 필수 항목입니다.
- 7
- 선택 사항: 이 매개변수를 사용하지 마십시오.
true로 설정하면 KMM이 일반 HTTP를 사용하여 컨테이너 이미지가 이미 존재하는지 확인할 수 있습니다. - 8
- 선택 사항: 이 매개변수를 사용하지 마십시오.
true로 설정하면 KMM은 컨테이너 이미지가 이미 존재하는지 확인할 때 모든 TLS 서버 인증서 검증을 건너뜁니다.
job.gcDelay 매개변수가 Operator 구성에 설정되어 있지 않은 한, 빌드가 성공하면 해당 빌드 포드는 즉시 가비지 수집됩니다. 실패한 빌드 포드는 항상 보존되며, 빌드를 다시 시작하려면 관리자가 수동으로 삭제해야 합니다.
4.10.3. Driver Toolkit 사용 링크 복사링크가 클립보드에 복사되었습니다!
Driver Toolkit (DTK)은 빌드 모듈 로더 이미지를 빌드하기 위한 편리한 기본 이미지입니다. 여기에는 현재 클러스터에서 실행 중인 OpenShift 버전의 툴과 라이브러리가 포함되어 있습니다.
프로세스
다단계 Dockerfile 의 첫 단계로 DTK를 사용합니다.
- 커널 모듈을 빌드합니다.
-
.ko파일을ubi-minimal과 같은 작은 최종 사용자 이미지에 복사합니다. 클러스터 내 빌드에서 DTK를 활용하려면
DTK_AUTO빌드 인수를 사용합니다. 이 값은Build리소스를 생성할 때 KMM에 의해 자동으로 설정됩니다. 다음 예제를 참조하십시오.ARG DTK_AUTO FROM ${DTK_AUTO} as builder ARG KERNEL_FULL_VERSION WORKDIR /usr/src RUN ["git", "clone", "https://github.com/rh-ecosystem-edge/kernel-module-management.git"] WORKDIR /usr/src/kernel-module-management/ci/kmm-kmod RUN KERNEL_SRC_DIR=/lib/modules/${KERNEL_FULL_VERSION}/build make all FROM ubi9/ubi-minimal ARG KERNEL_FULL_VERSION RUN microdnf install kmod COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_a.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ COPY --from=builder /usr/src/kernel-module-management/ci/kmm-kmod/kmm_ci_b.ko /opt/lib/modules/${KERNEL_FULL_VERSION}/ RUN depmod -b /opt ${KERNEL_FULL_VERSION}