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

2.3. KMM(커널 모듈 관리) 모듈에 대한 preflight 검증

적용된 KMM 모듈을 사용하여 클러스터에서 업그레이드를 수행하기 전에 KMM을 사용하여 설치된 커널 모듈이 클러스터 업그레이드 및 커널 업그레이드 후 노드에 설치할 수 있는지 확인해야 합니다. preflight는 클러스터에 로드된 모든 Module을 병렬로 검증하려고 합니다. preflight는 다른 Module의 검증을 시작하기 전에 하나의 Module의 유효성 검사가 완료될 때까지 기다리지 않습니다.

2.3.1. 검증 시작

preflight 검증은 클러스터에 PreflightValidationOCP 리소스를 생성하여 트리거됩니다. 이 사양에는 두 개의 필드가 있습니다.

releaseImage
클러스터가 업그레이드된 OpenShift Container Platform 버전의 릴리스 이미지 이름을 제공하는 필수 필드입니다.
pushBuiltImage
true 인 경우 Build 및 Sign 검증 중에 생성된 이미지가 해당 리포지토리로 푸시됩니다. 이 필드는 기본적으로 false입니다.

2.3.2. 검증 라이프사이클

preflight 검증은 클러스터에 로드된 모든 모듈을 검증하려고 합니다. preflight는 검증에 성공한 후 모듈 리소스에서 검증을 중지합니다. 모듈 검증에 실패하면 모듈 정의를 변경할 수 있으며, Preflight는 다음 루프에서 모듈을 다시 검증하려고 합니다.

추가 커널에 대해 Preflight 검증을 실행하려면 해당 커널에 대한 다른 PreflightValidationOCP 리소스를 생성해야 합니다. 모든 모듈을 검증한 후에는 PreflightValidationOCP 리소스를 삭제하는 것이 좋습니다.

2.3.3. 검증 상태

PreflightValidationOCP 리소스는 클러스터에 있는 각 모듈의 상태 및 진행 상황을 .status.modules 목록에서 시도하거나 검증하려고 했습니다. 해당 목록의 요소에는 다음 필드가 포함됩니다.

lastTransitionTime
모듈 리소스 상태가 한 상태에서 다른 상태로 전환된 마지막 시간입니다. 기본 상태가 변경된 경우여야 합니다. 이를 알 수 없는 경우 API 필드가 변경된 시간을 사용합니다.
name
모듈 리소스의 이름입니다.
네임스페이스
모듈 리소스의 네임스페이스입니다.
statusReason
상태에 대한 구두 설명입니다.
verificationStage

실행되는 검증 단계를 설명합니다.

  • 이미지: 이미지 존재 확인
  • Build: Build Process verification
  • 서명: 프로세스 확인 서명
verificationStatus

모듈 확인의 상태:

  • True: 확인
  • false: 확인 실패
  • error: 확인 프로세스 중 오류
  • 알 수 없음: 검증이 시작되지 않았습니다.

2.3.4. 모듈당 preflight 검증 단계

preflight는 클러스터에 있는 모든 KMM 모듈에 대해 다음 검증을 실행합니다.

  1. 이미지 검증 단계
  2. 빌드 검증 단계
  3. 검증 단계 서명

2.3.4.1. 이미지 검증 단계

이미지 검증은 실행할 사전 실행 검증의 첫 번째 단계입니다. 이미지 검증에 성공하면 해당 특정 모듈에서 다른 검증이 실행되지 않습니다.

이미지 검증은 다음 두 단계로 구성됩니다.

  1. 이미지 존재 및 접근성. 코드는 모듈에서 업그레이드된 커널에 대해 정의된 이미지에 액세스하여 매니페스트를 가져옵니다.
  2. 향후 modprobe 실행을 위해 Module 에 정의된 커널 모듈이 올바른 경로에 있는지 확인합니다. 이 검증에 성공하면 커널 모듈이 올바른 Linux 헤더로 컴파일되었음을 의미합니다. 올바른 경로는 < dirname>/lib/modules/<upgraded_kernel>/ 입니다.

2.3.4.2. 빌드 검증 단계

빌드 유효성 검사는 이미지 유효성 검사가 실패하고 업그레이드된 커널과 관련된 Module에 build 섹션이 있는 경우에만 실행됩니다. 빌드 검증은 빌드 작업을 실행하고 성공적으로 완료되었는지 확인합니다.

참고

다음과 같이 depmod 를 실행할 때 커널 버전을 지정해야 합니다. 

$ RUN depmod -b /opt ${KERNEL_VERSION}

Push builtImage 플래그가 PreflightValidationOCP CR(사용자 정의 리소스)에 정의된 경우 결과 이미지를 해당 리포지토리로 내보내려고 합니다. 결과 이미지 이름은 Module CR의 containerImage 필드 정의에서 가져옵니다.

참고

업그레이드된 커널에 대해 sign 섹션이 정의된 경우 결과 이미지는 Module CR의 containerImage 필드가 아니라 결과 이미지가 Sign flow의 제품이어야 하므로 임시 이미지 이름이 됩니다.

2.3.4.3. 검증 단계 서명

서명 검증은 이미지 검증에 실패한 경우에만 실행됩니다. 업그레이드 커널과 관련된 모듈 리소스에 기호 섹션이 있으며 업그레이드된 커널과 관련된 모듈에 빌드 섹션이 있는 경우 빌드 유효성 검사가 성공적으로 완료됩니다. 유효성 검사 시도에서 서명 작업을 실행하고 성공적으로 완료되었는지 확인합니다.

PreflightValidationOCP CR에 Push builtImage 플래그가 정의된 경우 서명 검증도 결과 이미지를 레지스트리로 푸시하려고 합니다. 결과 이미지는 항상 모듈의 ContainerImage 필드에 정의된 이미지입니다. 입력 이미지는 Build 단계의 출력이거나 UnsignedImage 필드에 정의된 이미지입니다.

참고

build 섹션이 있는 경우 sign 섹션 입력 이미지는 build 섹션의 출력 이미지입니다. 따라서 sign 섹션에 입력 이미지를 사용할 수 있으려면 PreflightValidationOCP CR에 Push builtImage 플래그를 정의해야 합니다.

2.3.5. PreflightValidationOCP 리소스의 예

이 섹션에서는 YAML 형식으로 PreflightValidationOCP 리소스의 예를 보여줍니다.

이 예제에서는 다음 릴리스 이미지가 가리키는 OpenShift Container Platform 릴리스 4.11.18에 포함된 향후 커널 버전에 대해 현재 존재하는 모든 모듈을 확인합니다. 

quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863

.spec.push builtImage 가 true 로 설정되므로 KMM은 빌드/로그인의 결과 이미지를 정의된 리포지토리로 내보냅니다. 

apiVersion: kmm.sigs.x-k8s.io/v1beta2
kind: PreflightValidationOCP
metadata:
  name: preflight
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863
  pushBuiltImage: true
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.