특수 하드웨어 및 드라이버 활성화
OpenShift Container Platform의 하드웨어 활성화 관련 정보
초록
1장. 특수 하드웨어 및 드라이버 활성화 정보
많은 애플리케이션에는 커널 모듈 또는 드라이버에 따라 달라지는 특수 하드웨어 또는 소프트웨어가 필요합니다. 드라이버 컨테이너를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS) 노드에서 트리 외부 (out-of-tree) 커널 모듈을 로드할 수 있습니다. 클러스터를 설치하는 동안 트리 외부 (out-of-tree) 드라이버를 배포하려면 kmods-via-containers
프레임워크를 사용합니다. 기존 OpenShift Container Platform 클러스터에서 드라이버 또는 커널 모듈을 로드하기 위해 OpenShift Container Platform에서는 다음과 같은 몇 가지 툴을 제공합니다.
- 드라이버 툴킷은 모든 OpenShift Container Platform 릴리스의 일부인 컨테이너 이미지입니다. 드라이버 또는 커널 모듈을 빌드하는 데 필요한 커널 패키지 및 기타 공통 종속성이 포함되어 있습니다. 드라이버 툴킷은 OpenShift Container Platform에서 드라이버 컨테이너 이미지 빌드의 기본 이미지로 사용할 수 있습니다.
- SRO(Special Resource Operator)는 기존 OpenShift 또는 Kubernetes 클러스터에서 커널 모듈과 드라이버를 로드하도록 드라이버 컨테이너의 빌드 및 관리를 오케스트레이션합니다.
- NFD(Node Feature Discovery) Operator는 CPU 기능, 커널 버전, PCIe 장치 벤더 ID 등에 대한 노드 레이블을 추가합니다.
2장. 드라이버 툴킷
드라이버 툴킷(Driver Toolkit)과 이 툴킷을 Kubernetes에서 특수 소프트웨어 및 하드웨어 장치를 활성화하기 위한 드라이버 컨테이너의 기본 이미지로 사용하는 방법에 대해 알아 보십시오.
드라이버 툴킷(Driver Toolkit)은 기술 프리뷰 기능으로만 사용할 수 있습니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
2.1. 드라이버 툴킷 정보
배경
Driver Toolkit은 드라이버 컨테이너를 빌드할 수 있는 기본 이미지로 사용되는 OpenShift Container Platform 페이로드의 컨테이너 이미지입니다. Driver Toolkit 이미지에는 커널 모듈을 빌드하거나 설치하는 데 일반적으로 필요한 커널 패키지와 드라이버 컨테이너에 필요한 몇 가지 툴이 포함되어 있습니다. 이러한 패키지의 버전은 해당 OpenShift Container Platform 릴리스의 RHCOS(Red Hat Enterprise Linux CoreOS) 노드에서 실행되는 커널 버전과 동일합니다.
드라이버 컨테이너는 RHCOS와 같은 컨테이너 운영 체제에서 트리 외부 커널 모듈 및 드라이버를 빌드하고 배포하는 데 사용되는 컨테이너 이미지입니다. 커널 모듈과 드라이버는 운영 체제 커널에서 높은 수준의 권한으로 실행되는 소프트웨어 라이브러리입니다. 커널 기능을 확장하거나 새 장치를 제어하는 데 필요한 하드웨어별 코드를 제공합니다. 예를 들어 Field Programmable Gate Arrays(예: Field Programmable Gate Arrays) 또는 GPU와 같은 하드웨어 장치, Lustre 병렬 파일 시스템과 같은 소프트웨어 정의 스토리지(SDS) 솔루션은 클라이언트 시스템에 커널 모듈이 필요합니다. 드라이버 컨테이너는 Kubernetes에서 이러한 기술을 활성화하는 데 사용되는 소프트웨어 스택의 첫 번째 계층입니다.
Driver Toolkit의 커널 패키지 목록에는 다음과 같은 종속성이 포함되어 있습니다.
-
kernel-core
-
kernel-devel
-
kernel-headers
-
kernel-modules
-
kernel-modules-extra
또한 Driver Toolkit에는 해당 실시간 커널 패키지도 포함되어 있습니다.
-
kernel-rt-core
-
kernel-rt-devel
-
kernel-rt-modules
-
kernel-rt-modules-extra
또한 Driver Toolkit에는 다음을 포함하여 커널 모듈을 빌드하고 설치하는 데 일반적으로 필요한 여러 도구가 있습니다.
-
elfutils-libelf-devel
-
kmod
-
binutilskabi-dw
-
kernel-abi-whitelists
- 위의 종속 항목
목적
Driver Toolkit이 출시하기 전에는 권한이 부여된 빌드를 사용하거나 호스트 machine-os-content
의 커널 RPM에서 설치하여 OpenShift Container Platform의 Pod에 커널 패키지를 설치할 수 있었습니다. Driver Toolkit은 인타이틀먼트 단계를 제거하여 프로세스를 간소화하고 Pod에서 machine-os-content에 액세스하는 권한 있는 작업을 피할 수 있습니다. Driver Toolkit은 사전 릴리스된 OpenShift Container Platform 버전에 액세스할 수 있는 파트너가 향후 OpenShift Container Platform 릴리스를 위한 하드웨어 장치용 드라이버 컨테이너를 사전 구축하는 데 사용할 수도 있습니다.
Driver Toolkit은 현재 OperatorHub에서 커뮤니티 Operator로 사용할 수 있는 SAR(Special Resource Operator)에서도 사용됩니다. SRO는 외부 및 타사 커널 드라이버와 기본 운영 체제에 대한 지원 소프트웨어를 지원합니다. SRO에 대한 레시피 를 생성하여 드라이버 컨테이너를 빌드하고 배포할 수 있으며 장치 플러그인 또는 메트릭과 같은 지원 소프트웨어를 생성할 수 있습니다. 레시피에는 Driver Toolkit을 기반으로 드라이버 컨테이너를 빌드하는 빌드 구성이 포함될 수 있으며, SRO는 사전 빌드된 드라이버 컨테이너를 배포할 수 있습니다.
2.2. Driver Toolkit 컨테이너 이미지 가져오기
driver-toolkit
이미지는 Red Hat Ecosystem Catalog의 컨테이너 이미지 섹션과 OpenShift Container Platform 릴리스 페이로드에서 사용할 수 있습니다. OpenShift Container Platform의 최신 마이너 릴리스에 해당하는 이미지에는 카탈로그의 버전 번호로 태그가 지정됩니다. 특정 릴리스의 이미지 URL은 oc adm
CLI 명령을 사용하여 찾을 수 있습니다.
2.2.1. registry.redhat.io에서 Driver Toolkit 컨테이너 이미지 가져오기
registry.redhat.io
에서 podman 또는 OpenShift Container Platform을 사용하여 driver-toolkit
이미지를 가져오는 방법은 Red Hat Ecosystem Catalog에서 확인할 수 있습니다. 최신 마이너 릴리스의 driver-toolkit 이미지는 registry.redhat.io/openshift4/driver-toolkit-rhel8:v4.11
의 마이너 릴리스 버전에 태그가 지정됩니다.
2.2.2. 페이로드에서 Driver Toolkit 이미지 URL 검색
사전 요구 사항
- Red Hat OpenShift Cluster Manager에서 이미지 풀 시크릿을 얻을 수 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다.
절차
특정 릴리스에 해당하는
driver-toolkit
의 이미지 URL은oc adm
명령을 사용하여 릴리스 이미지에서 얻을 수 있습니다.x86 이미지의 경우 명령은 다음과 같습니다.
$ oc adm release info quay.io/openshift-release-dev/ocp-release:{product-version}.z-x86_64 --image-for=driver-toolkit
ARM 이미지의 경우 명령은 다음과 같습니다.
$ oc adm release info quay.io/openshift-release-dev/ocp-release:{product-version}.z-aarch64 --image-for=driver-toolkit
출력 예
ocp-release:4.11.0-x86_64
이미지의 출력은 다음과 같습니다.quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:514e256367e8707e2c30f18a4f06fbd6c821ab9776602d2488e861f577a357d0
이 이미지는 OpenShift Container Platform을 설치하는 데 필요한 pull secret과 같은 유효한 풀 시크릿을 사용하여 가져올 수 있습니다.
$ podman pull --authfile=path/to/pullsecret.json quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:<SHA>
ARM 이미지는 64비트 type(AArch64)용으로만 빌드되며 현재 기술 프리뷰 기능입니다. ARM의 OpenShift Container Platform에 대한 자세한 내용은 릴리스 정보를 참조하십시오. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
2.3. Driver Toolkit 사용
예를 들어 Driver Toolkit은 simple-kmod라는 매우 간단한 커널 모듈을 빌드하기 위한 기본 이미지로 사용할 수 있습니다.
Driver Toolkit에는 커널 모듈에 서명하는 데 필요한 필수 종속성인 openssl
, mokutil
및 keyutils
가 포함되어 있습니다. 그러나 이 예에서는 simple-kmod 커널 모듈이 서명되지 않았으므로 Secure Boot
가 활성화된 시스템에서 로드할 수 없습니다.
2.3.1. 클러스터에서 simple-kmod 드라이버 컨테이너를 빌드하고 실행합니다.
사전 요구 사항
- 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
-
Image Registry Operator 상태를 클러스터의
Managed
로 설정합니다. -
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 OpenShift CLI에 로그인했습니다.
절차
네임스페이스를 생성합니다. 예를 들어 다음과 같습니다.
$ oc new-project simple-kmod-demo
YAML은
simple-kmod
드라이버 컨테이너 이미지를 저장하기 위한ImageStream
과 컨테이너 빌드를 위한BuildConfig
를 정의합니다. 이 YAML을0000-buildconfig.yaml.template
로 저장합니다.apiVersion: image.openshift.io/v1 kind: ImageStream metadata: labels: app: simple-kmod-driver-container name: simple-kmod-driver-container namespace: simple-kmod-demo spec: {} --- apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: labels: app: simple-kmod-driver-build name: simple-kmod-driver-build namespace: simple-kmod-demo spec: nodeSelector: node-role.kubernetes.io/worker: "" runPolicy: "Serial" triggers: - type: "ConfigChange" - type: "ImageChange" source: git: ref: "master" uri: "https://github.com/openshift-psap/kvc-simple-kmod.git" type: Git dockerfile: | FROM DRIVER_TOOLKIT_IMAGE WORKDIR /build/ # Expecting kmod software version as an input to the build ARG KMODVER # Grab the software from upstream RUN git clone https://github.com/openshift-psap/simple-kmod.git WORKDIR simple-kmod # Build and install the module RUN make all KVER=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}" kernel-core) KMODVER=${KMODVER} \ && make install KVER=$(rpm -q --qf "%{VERSION}-%{RELEASE}.%{ARCH}" kernel-core) KMODVER=${KMODVER} # Add the helper tools WORKDIR /root/kvc-simple-kmod ADD Makefile . ADD simple-kmod-lib.sh . ADD simple-kmod-wrapper.sh . ADD simple-kmod.conf . RUN mkdir -p /usr/lib/kvc/ \ && mkdir -p /etc/kvc/ \ && make install RUN systemctl enable kmods-via-containers@simple-kmod strategy: dockerStrategy: buildArgs: - name: KMODVER value: DEMO output: to: kind: ImageStreamTag name: simple-kmod-driver-container:demo
"DRIVER_TOOLKIT_IMAGE" 대신 실행 중인 OpenShift Container Platform 버전에 대해 올바른 드라이버 툴킷 이미지를 다음 명령으로 대체하십시오.
$ OCP_VERSION=$(oc get clusterversion/version -ojsonpath={.status.desired.version})
$ DRIVER_TOOLKIT_IMAGE=$(oc adm release info $OCP_VERSION --image-for=driver-toolkit)
$ sed "s#DRIVER_TOOLKIT_IMAGE#${DRIVER_TOOLKIT_IMAGE}#" 0000-buildconfig.yaml.template > 0000-buildconfig.yaml
이미지 스트림 및 빌드 구성을 만듭니다.
$ oc create -f 0000-buildconfig.yaml
빌더 Pod가 성공적으로 완료되면 드라이버 컨테이너 이미지를
DaemonSet
으로 배포합니다.호스트에서 커널 모듈을 로드하려면 드라이버 컨테이너를 권한 있는 보안 컨텍스트로 실행해야 합니다. 다음 YAML 파일에는 RBAC 규칙과 드라이버 컨테이너 실행을 위한
DaemonSet
이 포함되어 있습니다. 이 YAML을1000-drivercontainer.yaml
로 저장합니다.apiVersion: v1 kind: ServiceAccount metadata: name: simple-kmod-driver-container --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: simple-kmod-driver-container rules: - apiGroups: - security.openshift.io resources: - securitycontextconstraints verbs: - use resourceNames: - privileged --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: simple-kmod-driver-container roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: simple-kmod-driver-container subjects: - kind: ServiceAccount name: simple-kmod-driver-container userNames: - system:serviceaccount:simple-kmod-demo:simple-kmod-driver-container --- apiVersion: apps/v1 kind: DaemonSet metadata: name: simple-kmod-driver-container spec: selector: matchLabels: app: simple-kmod-driver-container template: metadata: labels: app: simple-kmod-driver-container spec: serviceAccount: simple-kmod-driver-container serviceAccountName: simple-kmod-driver-container containers: - image: image-registry.openshift-image-registry.svc:5000/simple-kmod-demo/simple-kmod-driver-container:demo name: simple-kmod-driver-container imagePullPolicy: Always command: ["/sbin/init"] lifecycle: preStop: exec: command: ["/bin/sh", "-c", "systemctl stop kmods-via-containers@simple-kmod"] securityContext: privileged: true nodeSelector: node-role.kubernetes.io/worker: ""
RBAC 규칙 및 데몬 세트를 생성합니다.
$ oc create -f 1000-drivercontainer.yaml
작업자 노드에서 pod가 실행된 후
lsmod
가 있는 호스트 시스템에simple_kmod
커널 모듈이 제대로 로드되었는지 확인합니다.pod가 실행 중인지 확인합니다.
$ oc get pod -n simple-kmod-demo
출력 예
NAME READY STATUS RESTARTS AGE simple-kmod-driver-build-1-build 0/1 Completed 0 6m simple-kmod-driver-container-b22fd 1/1 Running 0 40s simple-kmod-driver-container-jz9vn 1/1 Running 0 40s simple-kmod-driver-container-p45cc 1/1 Running 0 40s
드라이버 컨테이너 Pod에서
lsmod
명령을 실행합니다.$ oc exec -it pod/simple-kmod-driver-container-p45cc -- lsmod | grep simple
출력 예
simple_procfs_kmod 16384 0 simple_kmod 16384 0
2.4. 추가 리소스
- 클러스터의 레지스트리 스토리지 구성에 대한 자세한 내용은 OpenShift Container Platform의 Image Registry Operator 를 참조하십시오.
3장. SRO(Special Resource Operator)
SRO(Special Resource Operator)에 대해 알아보고 이를 사용하여 OpenShift Container Platform 클러스터의 노드에서 커널 모듈 및 장치 드라이버를 로드하기 위한 드라이버 컨테이너를 빌드 및 관리하는 방법에 대해 알아봅니다.
SRO(Special Resource Operator)는 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
3.1. SRO(Special Resource Operator) 정보
SRO(Special Resource Operator)를 사용하면 기존 OpenShift Container Platform 클러스터에서 커널 모듈 및 드라이버 배포를 관리할 수 있습니다. SRO는 단일 커널 모듈을 빌드하고 로드하거나 드라이버, 장치 플러그인 및 모니터링 스택을 하드웨어 가속기를 위한 배포만큼 간단하게 사용할 수 있습니다.
커널 모듈을 로드하기 위해 SRO는 드라이버 컨테이너 사용을 중심으로 설계되었습니다. 드라이버 컨테이너는 특히 순수 컨테이너 운영 체제에서 실행될 때 호스트에 하드웨어 드라이버를 제공하기 위해 클라우드 네이티브 환경에서 점점 더 많이 사용되고 있습니다. 드라이버 컨테이너는 기본적으로 제공되는 소프트웨어 및 특정 커널의 하드웨어 기능을 넘어 커널 스택을 확장합니다. 드라이버 컨테이너는 컨테이너 가능한 다양한 Linux 배포판에서 작동합니다. 드라이버 컨테이너를 사용하면 호스트 운영 체제가 깔끔하게 유지되며 호스트의 여러 라이브러리 버전이나 바이너리 간에 충돌이 발생하지 않습니다.
설명된 기능에는 네트워크에 대한 지속적인 연결로 연결된 환경이 필요합니다. 이러한 기능은 연결이 끊긴 환경에서 사용할 수 없습니다.
3.2. Special Resource Operator 설치
클러스터 관리자는 OpenShift CLI 또는 웹 콘솔을 사용하여 SRO(Special Resource Operator)를 설치할 수 있습니다.
3.2.1. CLI를 사용하여 Special Resource Operator 설치
클러스터 관리자는 OpenShift CLI를 사용하여 SRO(Special Resource Operator)를 설치할 수 있습니다.
사전 요구 사항
- 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 OpenShift CLI에 로그인했습니다.
절차
openshift-operators
네임스페이스에 SRO를 설치합니다.다음
Subscription
CR을 생성하고 YAML을sro-sub.yaml
파일에 저장합니다.서브스크립션 CR의 예
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-special-resource-operator namespace: openshift-operators spec: channel: "stable" installPlanApproval: Automatic name: openshift-special-resource-operator source: redhat-operators sourceNamespace: openshift-marketplace
다음 명령을 실행하여 서브스크립션 오브젝트를 생성합니다.
$ oc create -f sro-sub.yaml
openshift-operators
프로젝트로 전환합니다.$ oc project openshift-operators
검증
Operator 배포가 완료되었는지 확인하려면 다음을 실행합니다.
$ oc get pods
출력 예
NAME READY STATUS RESTARTS AGE nfd-controller-manager-7f4c5f5778-4lvvk 2/2 Running 0 89s special-resource-controller-manager-6dbf7d4f6f-9kl8h 2/2 Running 0 81s
성공적인 배포에는
Running
상태가 표시됩니다.
3.2.2. 웹 콘솔을 사용하여 Special Resource Operator 설치
클러스터 관리자는 OpenShift Container Platform 웹 콘솔을 사용하여 SRO(Special Resource Operator)를 설치할 수 있습니다.
절차
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
Special Resource Operator를 설치합니다.
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 Special Resource Operator를 선택한 다음 설치를 클릭합니다.
- Operator 설치 페이지에서 클러스터에서 특정 네임스페이스를 선택하고 이전 섹션에서 생성된 네임스페이스를 선택한 다음 설치를 클릭합니다.
검증
Special Resource Operator가 성공적으로 설치되었는지 확인하려면 다음을 수행합니다.
- Operator → 설치된 Operator 페이지로 이동합니다.
특수 리소스 Operator 가 openshift-operators 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.
참고설치하는 동안 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
- Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
-
워크로드 → Pod 페이지로 이동하여
openshift-operators
프로젝트에서 Pod 로그를 확인합니다.
3.3. Special Resource Operator 사용
SRO(Special Resource Operator)는 드라이버 컨테이너의 빌드 및 배포를 관리하는 데 사용됩니다. 컨테이너를 빌드하고 배포하는 데 필요한 오브젝트는 Helm 차트에 정의할 수 있습니다.
이 섹션의 예제에서는 simple-kmod SpecialResource
오브젝트를 사용하여 Helm 차트를 저장하기 위해 생성된 ConfigMap
오브젝트를 가리킵니다.
3.3.1. 구성 맵을 사용하여 simple-kmod SpecialResource 구축 및 실행
이 예에서 simple-kmod 커널 모듈은 SRO(Special Resource Operator)에서 드라이버 컨테이너를 관리하는 방법을 보여줍니다. 컨테이너는 구성 맵에 저장된 Helm 차트 템플릿에 정의되어 있습니다.
사전 요구 사항
- 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
-
Image Registry Operator 상태를 클러스터의
Managed
로 설정합니다. -
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 OpenShift CLI에 로그인했습니다. - NFD (Node Feature Discovery) Operator를 설치했습니다.
- SRO가 설치되어 있어야 합니다.
-
Helm CLI(
helm
)가 설치되어 있어야 합니다.
절차
simple-kmod
SpecialResource
오브젝트를 생성하려면 이미지 스트림과 빌드 구성을 정의하여 이미지를 빌드하고, 컨테이너를 실행하도록 서비스 계정, 역할, 역할 바인딩 및 데몬 세트를 정의합니다. 커널 모듈을 로드할 수 있도록 권한 있는 보안 컨텍스트로 데몬 세트를 실행하려면 서비스 계정, 역할 및 역할 바인딩이 필요합니다.templates
디렉터리를 생성하고 이 디렉터리로 변경합니다.$ mkdir -p chart/simple-kmod-0.0.1/templates
$ cd chart/simple-kmod-0.0.1/templates
이미지 스트림 및 빌드 구성에 대한 이 YAML 템플릿을
templates
디렉터리에0000-buildconfig.yaml
로 저장합니다.apiVersion: image.openshift.io/v1 kind: ImageStream metadata: labels: app: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} 1 name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} 2 spec: {} --- apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: labels: app: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverBuild}} 3 name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverBuild}} 4 annotations: specialresource.openshift.io/wait: "true" specialresource.openshift.io/driver-container-vendor: simple-kmod specialresource.openshift.io/kernel-affine: "true" spec: nodeSelector: node-role.kubernetes.io/worker: "" runPolicy: "Serial" triggers: - type: "ConfigChange" - type: "ImageChange" source: git: ref: {{.Values.specialresource.spec.driverContainer.source.git.ref}} uri: {{.Values.specialresource.spec.driverContainer.source.git.uri}} type: Git strategy: dockerStrategy: dockerfilePath: Dockerfile.SRO buildArgs: - name: "IMAGE" value: {{ .Values.driverToolkitImage }} {{- range $arg := .Values.buildArgs }} - name: {{ $arg.name }} value: {{ $arg.value }} {{- end }} - name: KVER value: {{ .Values.kernelFullVersion }} output: to: kind: ImageStreamTag name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}}:v{{.Values.kernelFullVersion}} 5
templates
디렉터리에 설정된 RBAC 리소스 및 데몬에 대한 다음 YAML 템플릿을1000-driver-container.yaml
로 저장합니다.apiVersion: v1 kind: ServiceAccount metadata: name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} rules: - apiGroups: - security.openshift.io resources: - securitycontextconstraints verbs: - use resourceNames: - privileged --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} subjects: - kind: ServiceAccount name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} namespace: {{.Values.specialresource.spec.namespace}} --- apiVersion: apps/v1 kind: DaemonSet metadata: labels: app: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} annotations: specialresource.openshift.io/wait: "true" specialresource.openshift.io/state: "driver-container" specialresource.openshift.io/driver-container-vendor: simple-kmod specialresource.openshift.io/kernel-affine: "true" specialresource.openshift.io/from-configmap: "true" spec: updateStrategy: type: OnDelete selector: matchLabels: app: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} template: metadata: labels: app: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} spec: priorityClassName: system-node-critical serviceAccount: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} serviceAccountName: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} containers: - image: image-registry.openshift-image-registry.svc:5000/{{.Values.specialresource.spec.namespace}}/{{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}}:v{{.Values.kernelFullVersion}} name: {{.Values.specialresource.metadata.name}}-{{.Values.groupName.driverContainer}} imagePullPolicy: Always command: ["/sbin/init"] lifecycle: preStop: exec: command: ["/bin/sh", "-c", "systemctl stop kmods-via-containers@{{.Values.specialresource.metadata.name}}"] securityContext: privileged: true nodeSelector: node-role.kubernetes.io/worker: "" feature.node.kubernetes.io/kernel-version.full: "{{.Values.KernelFullVersion}}"
chart/simple-kmod-0.0.1
디렉터리로 변경합니다.$ cd ..
차트에 대한 다음 YAML을
chart/simple-kmod-0.0.1
디렉터리에Chart.yaml
로 저장합니다.apiVersion: v2 name: simple-kmod description: Simple kmod will deploy a simple kmod driver-container icon: https://avatars.githubusercontent.com/u/55542927 type: application version: 0.0.1 appVersion: 1.0.0
chart
디렉토리에서hhelm package
명령을 사용하여 차트를 생성합니다.$ helm package simple-kmod-0.0.1/
출력 예
Successfully packaged chart and saved it to: /data/<username>/git/<github_username>/special-resource-operator/yaml-for-docs/chart/simple-kmod-0.0.1/simple-kmod-0.0.1.tgz
차트 파일을 저장할 구성 맵을 생성합니다.
구성 맵 파일의 디렉터리를 생성합니다.
$ mkdir cm
Helm 차트를
cm
디렉터리에 복사합니다.$ cp simple-kmod-0.0.1.tgz cm/simple-kmod-0.0.1.tgz
Helm 차트가 포함된 Helm 리포지터리를 지정하는 인덱스 파일을 생성합니다.
$ helm repo index cm --url=cm://simple-kmod/simple-kmod-chart
Helm 차트에 정의된 오브젝트의 네임스페이스를 생성합니다.
$ oc create namespace simple-kmod
구성 맵 오브젝트를 생성합니다.
$ oc create cm simple-kmod-chart --from-file=cm/index.yaml --from-file=cm/simple-kmod-0.0.1.tgz -n simple-kmod
구성 맵에서 생성한 Helm 차트를 사용하여 simple-kmod 오브젝트를 배포하려면 다음
SpecialResource
매니페스트를 사용합니다. 이 YAML을simple-kmod-configmap.yaml
로 저장합니다.apiVersion: sro.openshift.io/v1beta1 kind: SpecialResource metadata: name: simple-kmod spec: #debug: true 1 namespace: simple-kmod chart: name: simple-kmod version: 0.0.1 repository: name: example url: cm://simple-kmod/simple-kmod-chart 2 set: kind: Values apiVersion: sro.openshift.io/v1beta1 kmodNames: ["simple-kmod", "simple-procfs-kmod"] buildArgs: - name: "KMODVER" value: "SRO" driverContainer: source: git: ref: "master" uri: "https://github.com/openshift-psap/kvc-simple-kmod.git"
명령줄에서
SpecialResource
파일을 만듭니다.$ oc create -f simple-kmod-configmap.yaml
노드에서 simple-kmod 커널 모듈을 제거하려면 oc delete
명령을 사용하여 simple-kmod SpecialResource
API 오브젝트를 삭제합니다. 드라이버 컨테이너 Pod가 삭제되면 커널 모듈이 언로드됩니다.
검증
simple-kmod
리소스는 오브젝트 매니페스트에 지정된 대로 simple-kmod
네임스페이스에 배포됩니다. 잠시 후 simple-kmod
드라이버 컨테이너의 빌드 Pod가 실행되기 시작합니다. 몇 분 후에 빌드가 완료되면 드라이버 컨테이너 pod가 실행됩니다.
oc get pods
명령을 사용하여 빌드 Pod의 상태를 표시합니다.$ oc get pods -n simple-kmod
출력 예
NAME READY STATUS RESTARTS AGE simple-kmod-driver-build-12813789169ac0ee-1-build 0/1 Completed 0 7m12s simple-kmod-driver-container-12813789169ac0ee-mjsnh 1/1 Running 0 8m2s simple-kmod-driver-container-12813789169ac0ee-qtkff 1/1 Running 0 8m2s
oc logs
명령과 위의oc get pods
명령에서 얻은 빌드 Pod 이름을 사용하여 simple-kmod 드라이버 컨테이너 이미지 빌드의 로그를 표시합니다.$ oc logs pod/simple-kmod-driver-build-12813789169ac0ee-1-build -n simple-kmod
simple-kmod 커널 모듈이 로드되었는지 확인하려면 위의
oc get pods
명령에서 반환된 드라이버 컨테이너 Pod 중 하나에서lsmod
명령을 실행합니다.$ oc exec -n simple-kmod -it pod/simple-kmod-driver-container-12813789169ac0ee-mjsnh -- lsmod | grep simple
출력 예
simple_procfs_kmod 16384 0 simple_kmod 16384 0
sro_kind_completed_info
SRO Prometheus 지표는 배포되는 다양한 오브젝트의 상태에 대한 정보를 제공합니다. 이는 SRO CR 설치 문제를 해결하는 데 유용할 수 있습니다. SRO는 환경의 상태를 확인하는 데 사용할 수 있는 다른 유형의 메트릭도 제공합니다.
3.3.2. hub-and-spoke 토폴로지를 위한 simple-kmod SpecialResource를 구축하고 실행
hub-and-spoke 배포에서 Special Resource Operator(SRO)를 사용하여 hub 클러스터를 하나 이상의 관리 클러스터에 연결할 수 있습니다.
다음 예제 절차에서는 SRO가 허브에서 드라이버 컨테이너를 빌드하는 방법을 보여줍니다. SRO는 허브 클러스터 리소스를 감시하고 사용자 지정에 제공하는 리소스를 생성하는 데 사용하는 helm 차트의 OpenShift Container Platform 버전을 식별합니다.
사전 요구 사항
- 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 OpenShift CLI에 로그인했습니다. - SRO가 설치되어 있어야 합니다.
-
Helm CLI(
helm
)가 설치되어 있어야 합니다. - RHACM(Red Hat Advanced Cluster Management)을 설치했습니다.
- 컨테이너 레지스트리를 구성했습니다.
절차
다음 명령을 실행하여
templates
디렉터리를 생성합니다.$ mkdir -p charts/acm-simple-kmod-0.0.1/templates
다음 명령을 실행하여
templates
디렉터리로 변경합니다.$ cd charts/acm-simple-kmod-0.0.1/templates
BuildConfig
,Policy
및PlacementRule
리소스에 대한 템플릿 파일을 생성합니다.이미지 스트림에 대한 이 YAML 템플릿을 저장하고
templates
디렉터리에0001-buildconfig.yaml
로 .apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: labels: app: {{ printf "%s-%s" .Values.specialResourceModule.metadata.name .Values.kernelFullVersion | replace "." "-" | replace "_" "-" | trunc 63 }} name: {{ printf "%s-%s" .Values.specialResourceModule.metadata.name .Values.kernelFullVersion | replace "." "-" | replace "_" "-" | trunc 63 }} annotations: specialresource.openshift.io/wait: "true" spec: nodeSelector: node-role.kubernetes.io/worker: "" runPolicy: "Serial" triggers: - type: "ConfigChange" - type: "ImageChange" source: dockerfile: | FROM {{ .Values.driverToolkitImage }} as builder WORKDIR /build/ RUN git clone -b {{.Values.specialResourceModule.spec.set.git.ref}} {{.Values.specialResourceModule.spec.set.git.uri}} WORKDIR /build/simple-kmod RUN make all install KVER={{ .Values.kernelFullVersion }} FROM registry.redhat.io/ubi8/ubi-minimal RUN microdnf -y install kmod COPY --from=builder /etc/driver-toolkit-release.json /etc/ COPY --from=builder /lib/modules/{{ .Values.kernelFullVersion }}/* /lib/modules/{{ .Values.kernelFullVersion }}/ strategy: dockerStrategy: dockerfilePath: Dockerfile.SRO buildArgs: - name: "IMAGE" value: {{ .Values.driverToolkitImage }} {{- range $arg := .Values.buildArgs }} - name: {{ $arg.name }} value: {{ $arg.value }} {{- end }} - name: KVER value: {{ .Values.kernelFullVersion }} output: to: kind: DockerImage name: {{.Values.registry}}/{{.Values.specialResourceModule.metadata.name}}-{{.Values.groupName.driverContainer}}:{{.Values.kernelFullVersion}}
ACM 정책에 대한 이 YAML 템플릿을
templates
디렉터리에0002-policy.yaml
로 저장합니다.apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: policy-{{.Values.specialResourceModule.metadata.name}}-ds annotations: policy.open-cluster-management.io/categories: CM Configuration Management policy.open-cluster-management.io/controls: CM-2 Baseline Configuration policy.open-cluster-management.io/standards: NIST-CSF spec: remediationAction: enforce disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: config-{{.Values.specialResourceModule.metadata.name}}-ds spec: remediationAction: enforce severity: low namespaceselector: exclude: - kube-* include: - '*' object-templates: - complianceType: musthave objectDefinition: apiVersion: v1 kind: Namespace metadata: name: {{.Values.specialResourceModule.spec.namespace}} - complianceType: mustonlyhave objectDefinition: apiVersion: v1 kind: ServiceAccount metadata: name: {{.Values.specialResourceModule.metadata.name}} namespace: {{.Values.specialResourceModule.spec.namespace}} - complianceType: mustonlyhave objectDefinition: apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: {{.Values.specialResourceModule.metadata.name}} namespace: {{.Values.specialResourceModule.spec.namespace}} rules: - apiGroups: - security.openshift.io resources: - securitycontextconstraints verbs: - use resourceNames: - privileged - complianceType: mustonlyhave objectDefinition: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: {{.Values.specialResourceModule.metadata.name}} namespace: {{.Values.specialResourceModule.spec.namespace}} roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: {{.Values.specialResourceModule.metadata.name}} subjects: - kind: ServiceAccount name: {{.Values.specialResourceModule.metadata.name}} namespace: {{.Values.specialResourceModule.spec.namespace}} - complianceType: musthave objectDefinition: apiVersion: apps/v1 kind: DaemonSet metadata: labels: app: {{ printf "%s-%s" .Values.specialResourceModule.metadata.name .Values.kernelFullVersion | replace "." "-" | replace "_" "-" | trunc 63 }} name: {{ printf "%s-%s" .Values.specialResourceModule.metadata.name .Values.kernelFullVersion | replace "." "-" | replace "_" "-" | trunc 63 }} namespace: {{.Values.specialResourceModule.spec.namespace}} spec: updateStrategy: type: OnDelete selector: matchLabels: app: {{ printf "%s-%s" .Values.specialResourceModule.metadata.name .Values.kernelFullVersion | replace "." "-" | replace "_" "-" | trunc 63 }} template: metadata: labels: app: {{ printf "%s-%s" .Values.specialResourceModule.metadata.name .Values.kernelFullVersion | replace "." "-" | replace "_" "-" | trunc 63 }} spec: priorityClassName: system-node-critical serviceAccount: {{.Values.specialResourceModule.metadata.name}} serviceAccountName: {{.Values.specialResourceModule.metadata.name}} containers: - image: {{.Values.registry}}/{{.Values.specialResourceModule.metadata.name}}-{{.Values.groupName.driverContainer}}:{{.Values.kernelFullVersion}} name: {{.Values.specialResourceModule.metadata.name}} imagePullPolicy: Always command: [sleep, infinity] lifecycle: preStop: exec: command: ["modprobe", "-r", "-a" , "simple-kmod", "simple-procfs-kmod"] securityContext: privileged: true
templates
디렉터리에 정책을 배치하기 위해 이 YAML 템플릿을0003-policy.yaml
로 저장합니다.apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: {{.Values.specialResourceModule.metadata.name}}-placement spec: clusterConditions: - status: "True" type: ManagedClusterConditionAvailable clusterSelector: matchExpressions: - key: name operator: NotIn values: - local-cluster --- apiVersion: policy.open-cluster-management.io/v1 kind: PlacementBinding metadata: name: {{.Values.specialResourceModule.metadata.name}}-binding placementRef: apiGroup: apps.open-cluster-management.io kind: PlacementRule name: {{.Values.specialResourceModule.metadata.name}}-placement subjects: - apiGroup: policy.open-cluster-management.io kind: Policy name: policy-{{.Values.specialResourceModule.metadata.name}}-ds
다음 명령을 실행하여
charts/acm-simple-kmod-0.0.1
디렉토리로 변경합니다.cd ..
차트에 대한 다음 YAML 템플릿을
charts/acm-simple-kmod-0.0.1
디렉터리에Chart.yaml
로 저장합니다.apiVersion: v2 name: acm-simple-kmod description: Build ACM enabled simple-kmod driver with SpecialResourceOperator icon: https://avatars.githubusercontent.com/u/55542927 type: application version: 0.0.1 appVersion: 1.6.4
차트
디렉터리에서 명령을 사용하여 차트를 만듭니다.$ helm package acm-simple-kmod-0.0.1/
출력 예
Successfully packaged chart and saved it to: <directory>/charts/acm-simple-kmod-0.0.1.tgz
차트 파일을 저장할 구성 맵을 만듭니다.
다음 명령을 실행하여 구성 맵 파일의 디렉터리를 생성합니다.
$ mkdir cm
다음 명령을 실행하여 Helm 차트를
cm
디렉터리에 복사합니다.$ cp acm-simple-kmod-0.0.1.tgz cm/acm-simple-kmod-0.0.1.tgz
다음 명령을 실행하여 Helm 차트가 포함된 Helm 리포지터리를 지정하는 인덱스 파일을 생성합니다.
$ helm repo index cm --url=cm://acm-simple-kmod/acm-simple-kmod-chart
다음 명령을 실행하여 Helm 차트에 정의된 오브젝트의 네임스페이스를 생성합니다.
$ oc create namespace acm-simple-kmod
다음 명령을 실행하여 구성 맵 오브젝트를 생성합니다.
$ oc create cm acm-simple-kmod-chart --from-file=cm/index.yaml --from-file=cm/acm-simple-kmod-0.0.1.tgz -n acm-simple-kmod
다음
SpecialResourceModule
매니페스트를 사용하여 구성 맵에서 만든 Helm 차트를 사용하여simple-kmod
오브젝트를 배포합니다. 이 YAML 파일을acm-simple-kmod.yaml
로 저장합니다.apiVersion: sro.openshift.io/v1beta1 kind: SpecialResourceModule metadata: name: acm-simple-kmod spec: namespace: acm-simple-kmod chart: name: acm-simple-kmod version: 0.0.1 repository: name: acm-simple-kmod url: cm://acm-simple-kmod/acm-simple-kmod-chart set: kind: Values apiVersion: sro.openshift.io/v1beta1 buildArgs: - name: "KMODVER" value: "SRO" registry: <your_registry> 1 git: ref: master uri: https://github.com/openshift-psap/kvc-simple-kmod.git watch: - path: "$.metadata.labels.openshiftVersion" apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster name: spoke1
- 1
- 구성한 레지스트리의 URL을 지정합니다.
다음 명령을 실행하여 특수 리소스 모듈을 생성합니다.
$ oc apply -f charts/examples/acm-simple-kmod.yaml
검증
다음 명령을 실행하여 빌드 Pod의 상태를 확인합니다.
$ KUBECONFIG=~/hub/auth/kubeconfig oc get pod -n acm-simple-kmod
출력 예
NAME READY STATUS RESTARTS AGE acm-simple-kmod-4-18-0-305-34-2-el8-4-x86-64-1-build 0/1 Completed 0 42m
다음 명령을 실행하여 정책이 생성되었는지 확인합니다.
$ KUBECONFIG=~/hub/auth/kubeconfig oc get placementrules,placementbindings,policies -n acm-simple-kmod
출력 예
NAME AGE REPLICAS placementrule.apps.open-cluster-management.io/acm-simple-kmod-placement 40m NAME AGE placementbinding.policy.open-cluster-management.io/acm-simple-kmod-binding 40m NAME REMEDIATION ACTION COMPLIANCE STATE AGE policy.policy.open-cluster-management.io/policy-acm-simple-kmod-ds enforce Compliant 40m
다음 명령을 실행하여 리소스가 조정되었는지 확인합니다.
$ KUBECONFIG=~/hub/auth/kubeconfig oc get specialresourcemodule acm-simple-kmod -o json | jq -r '.status'
출력 예
{ "versions": { "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:6a3330ef5a178435721ff4efdde762261a9c55212e9b4534385e04037693fbe4": { "complete": true } } }
다음 명령을 실행하여 리소스가 스포크에서 실행되고 있는지 확인합니다.
$ KUBECONFIG=~/spoke1/kubeconfig oc get ds,pod -n acm-simple-kmod
출력 예
AME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/acm-simple-kmod-4-18-0-305-45-1-el8-4-x86-64 3 3 3 3 3 <none> 26m NAME READY STATUS RESTARTS AGE pod/acm-simple-kmod-4-18-0-305-45-1-el8-4-x86-64-brw78 1/1 Running 0 26m pod/acm-simple-kmod-4-18-0-305-45-1-el8-4-x86-64-fqh5h 1/1 Running 0 26m pod/acm-simple-kmod-4-18-0-305-45-1-el8-4-x86-64-m9sfd 1/1 Running 0 26m
3.4. Prometheus Special Resource Operator 지표
SAR(Special Resource Operator)은 메트릭 서비스를 통해 다음 Prometheus 지표
를 노출합니다.
메트릭 이름 | 설명 |
---|---|
|
SRO CR(사용자 정의 리소스)에서 생성한 Pod를 실행하는 노드를 반환합니다. 이 메트릭은 |
|
SRO CR의 Helm 차트에서 정의한 |
|
SRO가 CR 처리를 성공적으로 완료했는지(값 |
| 상태에 관계없이 클러스터의 SRO CR 수를 반환합니다. |
3.5. 추가 리소스
- Special Resource Operator를 사용하기 전에 Image Registry Operator 상태를 복원하는 방법에 대한 자세한 내용은 설치 중에 제거된 이미지 레지스트리 를 참조하십시오.
- NFD Operator 설치에 대한 자세한 내용은 NFD(Node Feature Discovery) Operator 를 참조하십시오.
- Special Resource Operator가 포함된 클러스터 업데이트에 대한 자세한 내용은 Special Resource Operator 가 포함된 클러스터 업데이트를 참조하십시오.
4장. Node Feature Discovery Operator
Node Feature Discovery (NFD) Operator 및 이를 사용하여 하드웨어 기능과 시스템 구성을 감지하기 위한 Kubernetes 애드온 기능인 NFD(Node Feature Discovery)을 오케스트레이션하여 노드 수준 정보를 공개하는 방법을 설명합니다.
4.1. Node Feature Discovery Operator 정보
NFD(Node Feature Discovery Operator)는 하드웨어 관련 정보로 노드에 레이블을 지정하여 OpenShift Container Platform 클러스터에서 하드웨어 기능 및 구성 검색을 관리합니다. NFD는 PCI 카드, 커널, 운영 체제 버전과 같은 노드별 속성을 사용하여 호스트에 레이블을 지정합니다.
NFD Operator는 "Node Feature Discovery"을 검색하여 Operator Hub에서 확인할 수 있습니다.
4.2. Node Feature Discovery Operator 설치
NFD(Node Feature Discovery) Operator는 NFD 데몬 세트를 실행하는 데 필요한 모든 리소스를 오케스트레이션합니다. 클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 NFD Operator를 설치할 수 있습니다.
4.2.1. CLI를 사용하여 NFD Operator 설치
클러스터 관리자는 CLI를 사용하여 NFD Operator를 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
절차
NFD Operator의 네임스페이스를 생성합니다.
openshift-nfd
네임스페이스를 정의하는 다음Namespace
CR(사용자 정의 리소스)을 생성하고nfd-namespace.yaml
파일에 YAML을 저장합니다.apiVersion: v1 kind: Namespace metadata: name: openshift-nfd
다음 명령을 실행하여 네임스페이스를 생성합니다.
$ oc create -f nfd-namespace.yaml
다음 오브젝트를 생성하여 이전 단계에서 생성한 네임스페이스에 NFD Operator를 설치합니다.
다음
OperatorGroup
CR을 생성하고 해당 YAML을nfd-operatorgroup.yaml
파일에 저장합니다.apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: generateName: openshift-nfd- name: openshift-nfd namespace: openshift-nfd spec: targetNamespaces: - openshift-nfd
다음 명령을 실행하여
OperatorGroup
CR을 생성합니다.$ oc create -f nfd-operatorgroup.yaml
다음
Subscription
CR을 생성하고 해당 YAML을nfd-sub.yaml
파일에 저장합니다.서브스크립션의 예
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: nfd namespace: openshift-nfd spec: channel: "stable" installPlanApproval: Automatic name: nfd source: redhat-operators sourceNamespace: openshift-marketplace
다음 명령을 실행하여 서브스크립션 오브젝트를 생성합니다.
$ oc create -f nfd-sub.yaml
openshift-nfd
프로젝트로 변경합니다.$ oc project openshift-nfd
검증
Operator 배포가 완료되었는지 확인하려면 다음을 실행합니다.
$ oc get pods
출력 예
NAME READY STATUS RESTARTS AGE nfd-controller-manager-7f86ccfb58-vgr4x 2/2 Running 0 10m
성공적인 배포에는
Running
상태가 표시됩니다.
4.2.2. 웹 콘솔을 사용하여 NFD Operator 설치
클러스터 관리자는 웹 콘솔을 사용하여 NFD Operator를 설치할 수 있습니다.
절차
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 Node Feature Discovery를 선택한 다음 설치를 클릭합니다.
- Operator 설치 페이지에서 클러스터의 특정 네임스페이스를 선택한 다음 설치를 클릭합니다. 네임스페이스가 생성되므로 생성할 필요가 없습니다.
검증
다음과 같이 NFD Operator가 설치되었는지 확인합니다.
- Operator → 설치된 Operator 페이지로 이동합니다.
Node Feature Discovery가 openshift-nfd 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.
참고설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
문제 해결
Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
- Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
-
Workloads → Pod 페이지로 이동하여
openshift-nfd
프로젝트에서 Pod 로그를 확인합니다.
4.3. Node Feature Discovery Operator 사용
NFD(Node Feature Discovery) Operator는 NodeFeatureDiscovery
CR을 확인하여 Node-Versionature-Discovery 데몬 세트를 실행하는 데 필요한 모든 리소스를 오케스트레이션합니다. NodefeatureatureDiscovery
CR을 기반으로 Operator는 원하는 네임스페이스에 피연산자(NFD) 구성 요소를 생성합니다. CR을 편집하여 다른 옵션 중에서 다른 namespace
, image
, imagePullPolicy
, nfd-worker-conf
를 선택할 수 있습니다.
클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 NodeFeatureDiscovery
인스턴스를 만들 수 있습니다.
4.3.1. CLI를 사용하여 NodeEnatureDiscovery 인스턴스 생성
클러스터 관리자는 CLI를 사용하여 NodefeatureatureDiscovery
CR 인스턴스를 생성할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - NFD Operator를 설치합니다.
절차
다음
NodeEnatureDiscovery
사용자 정의 리소스(CR)를 생성한 다음 YAML을NodefeatureatureDiscovery.yaml
파일에 저장합니다.apiVersion: nfd.openshift.io/v1 kind: NodeFeatureDiscovery metadata: name: nfd-instance namespace: openshift-nfd spec: instance: "" # instance is empty by default topologyupdater: false # False by default operand: image: registry.redhat.io/openshift4/ose-node-feature-discovery:v4.11 imagePullPolicy: Always workerConfig: configData: | core: # labelWhiteList: # noPublish: false sleepInterval: 60s # sources: [all] # klog: # addDirHeader: false # alsologtostderr: false # logBacktraceAt: # logtostderr: true # skipHeaders: false # stderrthreshold: 2 # v: 0 # vmodule: ## NOTE: the following options are not dynamically run-time configurable ## and require a nfd-worker restart to take effect after being changed # logDir: # logFile: # logFileMaxSize: 1800 # skipLogHeaders: false sources: cpu: cpuid: # NOTE: whitelist has priority over blacklist attributeBlacklist: - "BMI1" - "BMI2" - "CLMUL" - "CMOV" - "CX16" - "ERMS" - "F16C" - "HTT" - "LZCNT" - "MMX" - "MMXEXT" - "NX" - "POPCNT" - "RDRAND" - "RDSEED" - "RDTSCP" - "SGX" - "SSE" - "SSE2" - "SSE3" - "SSE4.1" - "SSE4.2" - "SSSE3" attributeWhitelist: kernel: kconfigFile: "/path/to/kconfig" configOpts: - "NO_HZ" - "X86" - "DMI" pci: deviceClassWhitelist: - "0200" - "03" - "12" deviceLabelFields: - "class" customConfig: configData: | - name: "more.kernel.features" matchOn: - loadedKMod: ["example_kmod3"]
NFD 작업자를 사용자 지정하는 방법에 대한 자세한 내용은 nfd-worker의 구성 파일 참조 를 참조하십시오.
다음 명령어를 실행하여
NodeFeatureDiscovery
CR 인스턴스를 만듭니다.$ oc create -f NodeFeatureDiscovery.yaml
검증
인스턴스가 생성되었는지 확인하려면 다음을 실행합니다.
$ oc get pods
출력 예
NAME READY STATUS RESTARTS AGE nfd-controller-manager-7f86ccfb58-vgr4x 2/2 Running 0 11m nfd-master-hcn64 1/1 Running 0 60s nfd-master-lnnxx 1/1 Running 0 60s nfd-master-mp6hr 1/1 Running 0 60s nfd-worker-vgcz9 1/1 Running 0 60s nfd-worker-xqbws 1/1 Running 0 60s
성공적인 배포에는
Running
상태가 표시됩니다.
4.3.2. 웹 콘솔을 사용하여 NodeEnatureDiscovery CR 만들기
절차
- Operator → 설치된 Operator 페이지로 이동합니다.
- Node Feature Discovery를 찾고 제공된 APIs아래에 있는 상자를 확인합니다.
- 인스턴스 만들기를 클릭합니다.
-
NodefeatureatureDiscovery
CR의 값을 편집합니다. - 생성을 클릭합니다.
4.4. Node Feature Discovery Operator 설정
4.4.1. 코어
core
섹션에는 특정 기능 소스와 관련이 없는 일반적인 구성 설정이 포함되어 있습니다.
core.sleepInterval
core.sleepInterval
은 기능 검색 또는 재검색의 연속 통과 간격과 노드 레이블 재지정 간격을 지정합니다. 양수가 아닌 값은 무한 절전 상태를 의미합니다. 재검색되거나 레이블이 다시 지정되지 않습니다.
이 값은 지정된 경우 더 이상 사용되지 않는 --sleep-interval
명령줄 플래그로 재정의됩니다.
사용 예
core:
sleepInterval: 60s 1
기본값은 60s
입니다.
core.sources
core.sources는
활성화된 기능 소스 목록을 지정합니다. 특수한 값 all
은 모든 기능 소스를 활성화합니다.
이 값은 지정된 경우 더 이상 사용되지 않는 --sources
명령줄 플래그로 재정의됩니다.
기본값: [all]
사용 예
core: sources: - system - custom
core.labelWhiteList
core.labelWhiteList
는 레이블 이름을 기반으로 기능 레이블을 필터링하기 위한 정규식을 지정합니다. 일치하지 않는 레이블은 게시되지 않습니다.
정규 표현식은 레이블의 기반 이름 부분인 '/' 뒤에 있는 이름의 부분과만 일치합니다. 레이블 접두사 또는 네임스페이스가 생략됩니다.
이 값은 지정된 경우 더 이상 사용되지 않는 --label-whitelist
명령줄 플래그로 재정의됩니다.
기본값: null
사용 예
core: labelWhiteList: '^cpu-cpuid'
core.noPublish
core.noPublish
를 true
로 설정하면 nfd-master
와의 모든 통신이 비활성화됩니다. 이것은 실질적으로는 드라이런 플래그입니다. nfd-worker
는 정상적으로 기능 감지를 실행하지만 레이블 요청은 nfd-master
로 전송되지 않습니다.
이 값은 지정된 경우 --no-publish
명령줄 플래그로 재정의됩니다.
예제:
사용 예
core:
noPublish: true 1
기본값은 false
입니다.
core.klog
다음 옵션은 대부분 런타임에 동적으로 조정할 수 있는 로거 구성을 지정합니다.
로거 옵션은 명령줄 플래그를 사용하여 지정할 수도 있으며, 이러한 옵션은 해당 구성 파일 옵션보다 우선합니다.
core.klog.addDirHeader
true
로 설정하면core.klog.addDirHeader
에서 파일 디렉터리를 로그 메시지의 헤더에 추가합니다.
기본값: false
런타임 설정 가능: yes
core.klog.alsologtostderr
표준 오류 및 파일에 기록합니다.
기본값: false
런타임 설정 가능: yes
core.klog.logBacktraceAt
로깅이 file:N 행에 도달하면 스택 추적을 출력합니다.
기본값: empty
런타임 설정 가능: yes
core.klog.logDir
비어 있지 않은 경우 이 디렉터리에 로그 파일을 작성합니다.
기본값: empty
런타임 설정 가능: no
core.klog.logFile
비어 있지 않은 경우 이 로그 파일을 사용합니다.
기본값: empty
런타임 설정 가능: no
core.klog.logFileMaxSize
core.klog.logFileMaxSize
는 로그 파일의 최대 크기를 정의합니다. 단위는 메가바이트입니다. 값이 0
인 경우 최대 파일 크기는 무제한입니다.
기본값: 1800
런타임 설정 가능: no
core.klog.logtostderr
파일 대신 표준 오류에 기록합니다.
기본값: true
런타임 설정 가능: yes
core.klog.skipHeaders
core.klog.skipHeaders
가 true
로 설정된 경우 로그 메시지에서 헤더 접두사를 사용하지 않습니다.
기본값: false
런타임 설정 가능: yes
core.klog.skipLogHeaders
core.klog.skipLogHeaders
가 true
로 설정된 경우 로그 파일을 열 때 헤더를 사용하지 않습니다.
기본값: false
런타임 설정 가능: no
core.klog.stderrthreshold
임계값 이상의 로그는 stderr에 있습니다.
기본값: 2
런타임 설정 가능: yes
core.klog.v
core.klog.v
는 로그 수준 세부 정보 표시의 수치입니다.
기본값: 0
런타임 설정 가능: yes
core.klog.vmodule
core.klog.vmodule
은 파일 필터링된 로깅의 쉼표로 구분된 pattern=N
설정 목록입니다.
기본값: empty
런타임 설정 가능: yes
4.4.2. 소스
source
섹션에는 기능 소스 관련 구성 매개변수가 포함되어 있습니다.
sources.cpu.cpuid.attributeBlacklist
이 옵션에 나열된 cpuid
기능만을 공개합니다.
이 값은 sources.cpu.cpuid.attributeWhitelist로
에 의해 재정의됩니다.
기본값: [BMI1, BMI2, CLMUL, CMOV, CX16, ERMS, F16C, HTT, LZCNT, MMX, MMXEXT, NX, POPCNT, RDRAND, RDSEED, RDTSCP, SGX, SGXLC, SSE, SSE2, SSE3, SSE4.1, SSE4.2, SSSE3]
사용 예
sources: cpu: cpuid: attributeBlacklist: [MMX, MMXEXT]
sources.cpu.cpuid.attributeWhitelist
이 옵션에 나열된 cpuid
기능만 게시합니다.
sources.cpu.cpuid.attributeWhitelist
는 sources.cpu.cpuid.attributeBlacklist
보다 우선합니다.
기본값: empty
사용 예
sources: cpu: cpuid: attributeWhitelist: [AVX512BW, AVX512CD, AVX512DQ, AVX512F, AVX512VL]
sources.kernel.kconfigFile
sources.kernel.kconfigFile
은 커널 구성 파일의 경로입니다. 비어 있는 경우 NFD는 일반적인 표준 위치에서 검색을 실행합니다.
기본값: empty
사용 예
sources: kernel: kconfigFile: "/path/to/kconfig"
sources.kernel.configOpts
Source.kernel.configOpts
는 기능 레이블로 게시하는 커널 구성 옵션을 나타냅니다.
기본값: [NO_HZ, NO_HZ_IDLE, NO_HZ_FULL, PREEMPT]
사용 예
sources: kernel: configOpts: [NO_HZ, X86, DMI]
sources.pci.deviceClassWhitelist
sources.pci.deviceClassWhitelist
는 레이블을 게시할 PCI 장치 클래스 ID 목록입니다. 메인 클래스로만 (예: 03
) 또는 전체 클래스-하위 클래스 조합(예: 0300
)으로 지정할 수 있습니다. 전자는 모든 하위 클래스가 허용됨을 의미합니다. 레이블 형식은 deviceLabelFields
를 사용하여 추가로 구성할 수 있습니다.
기본값: ["03", "0b40", "12"]
사용 예
sources: pci: deviceClassWhitelist: ["0200", "03"]
sources.pci.deviceLabelFields
sources.pci.deviceLabelFields
는 기능 레이블의 이름을 구성할 때 사용할 PCI ID 필드 집합입니다. 유효한 필드는 class
,vendor
,device
,subsystem_vendor
및 subsystem_device
입니다.
기본값: [class, vendor]
사용 예
sources: pci: deviceLabelFields: [class, vendor, device]
위의 설정 예제에서 NFD는 feature.node.kubernetes.io/pci-<class-id>_<vendor-id>_<device-id>.present=true
와 같은 레이블을 게시합니다.
sources.usb.deviceClassWhitelist
sources.usb.deviceClassWhitelist
는 기능 레이블을 게시하는 USB 장치 클래스 ID 목록입니다. 레이블 형식은 deviceLabelFields
를 사용하여 추가로 구성할 수 있습니다.
기본값: ["0e", "ef", "fe", "ff"]
사용 예
sources: usb: deviceClassWhitelist: ["ef", "ff"]
sources.usb.deviceLabelFields
sources.usb.deviceLabelFields
는 기능 레이블의 이름을 작성할 USB ID 필드 집합입니다. 유효한 필드는 class
,vendor
, device
입니다.
기본값: [class, vendor, device]
사용 예
sources: pci: deviceLabelFields: [class, vendor]
위의 config 예제에서 NFD는 feature.node.kubernetes.io/usb-<class-id>_<vendor-id>.present=true
와 같은 레이블을 게시합니다.
sources.custom
sources.custom
은 사용자별 레이블을 생성하기 위해 사용자 정의 기능 소스에서 처리할 규칙 목록입니다.
기본값: empty
사용 예
source: custom: - name: "my.custom.feature" matchOn: - loadedKMod: ["e1000e"] - pciId: class: ["0200"] vendor: ["8086"]
4.5. NFD 토폴로지 업데이트 프로그램 사용
NFD(Node Feature Discovery) Topology Updater는 작업자 노드에서 할당된 리소스를 검사하는 데몬입니다. 이 노드는 영역별로 새 Pod에 할당할 수 있는 리소스를 차지하며, 여기서 영역이 NUMA(Non-Uniform Memory Access) 노드일 수 있습니다. NFD 토폴로지 업데이트 프로그램은 해당 정보를 nfd-master와 통신하며 클러스터의 모든 작업자 노드에 해당하는 NodeResourceTopology
CR(사용자 정의 리소스)을 생성합니다. NFD 토폴로지 업데이트 프로그램의 한 인스턴스가 클러스터의 각 노드에서 실행됩니다.
NFD에서 토폴로지 업데이트 작업자를 활성화하려면 NodeFeatureDiscovery
CR에서 topologyupdater
변수를 true
로 설정합니다. Node Feature Discovery Operator를 사용하는 섹션에 설명된 대로 다음을 수행합니다.
4.5.1. NodeResourceTopology CR
NFD Topology Updater를 사용하여 실행하는 경우 NFD는 다음과 같은 노드 리소스 하드웨어 토폴로지에 해당하는 사용자 정의 리소스 인스턴스를 생성합니다.
apiVersion: topology.node.k8s.io/v1alpha1 kind: NodeResourceTopology metadata: name: node1 topologyPolicies: ["SingleNUMANodeContainerLevel"] zones: - name: node-0 type: Node resources: - name: cpu capacity: 20 allocatable: 16 available: 10 - name: vendor/nic1 capacity: 3 allocatable: 3 available: 3 - name: node-1 type: Node resources: - name: cpu capacity: 30 allocatable: 30 available: 15 - name: vendor/nic2 capacity: 6 allocatable: 6 available: 6 - name: node-2 type: Node resources: - name: cpu capacity: 30 allocatable: 30 available: 15 - name: vendor/nic1 capacity: 3 allocatable: 3 available: 3
4.5.2. NFD Topology Updater 명령줄 플래그
사용 가능한 명령줄 플래그를 보려면 nfd-topology-updater -help
명령을 실행합니다. 예를 들어 podman 컨테이너에서 다음 명령을 실행합니다.
$ podman run gcr.io/k8s-staging-nfd/node-feature-discovery:master nfd-topology-updater -help
-ca-file
-ca-file
플래그는 NFD Topology Updater에서 상호 TLS 인증을 제어하는 -cert-file
및 '-key-file'flags와 함께 세 가지 플래그 중 하나입니다. 이 플래그는 nfd-master의 진위 여부를 확인하는 데 사용되는 TLS 루트 인증서를 지정합니다.
기본값: empty
-ca-file
플래그는 -cert-file
및 -key-file
플래그와 함께 지정해야 합니다.
예제
$ nfd-topology-updater -ca-file=/opt/nfd/ca.crt -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key
-cert-file
cert-file
플래그는 NFD Topology Updater에서 상호 TLS 인증을 제어하는 -ca-file
및 -key-file 플래그
와 함께 세 가지 플래그 중 하나입니다. 이 플래그는 발신 요청을 인증하기 위해 제공되는 TLS 인증서를 지정합니다.
기본값: empty
-cert-file
플래그는 -ca-file
및 -key-file
플래그와 함께 지정해야 합니다.
예제
$ nfd-topology-updater -cert-file=/opt/nfd/updater.crt -key-file=/opt/nfd/updater.key -ca-file=/opt/nfd/ca.crt
-h, -help
사용량을 출력하고 종료합니다.
-key-file
-key-file
플래그는 NFD Topology Updater에서 상호 TLS 인증을 제어하는 -ca-file
및 -cert-file
플래그와 함께 세 가지 플래그 중 하나입니다. 이 플래그는 발신 요청을 인증하는 데 사용되는 지정된 인증서 파일 또는 -cert-file
에 해당하는 개인 키를 지정합니다.
기본값: empty
-key-file
플래그는 -ca-file
및 -cert-file
플래그와 함께 지정해야 합니다.
예제
$ nfd-topology-updater -key-file=/opt/nfd/updater.key -cert-file=/opt/nfd/updater.crt -ca-file=/opt/nfd/ca.crt
-kubelet-config-file
-kubelet-config-file
은 Kubelet의 구성 파일의 경로를 지정합니다.
기본값: /host-var/lib/kubelet/config.yaml
예제
$ nfd-topology-updater -kubelet-config-file=/var/lib/kubelet/config.yaml
-no-publish
no-publish
플래그는 nfd-master와의 모든 통신을 비활성화하여 nfd-topology-updater에 대한 예행 실행 플래그를 지정합니다. NFD Topology Updater는 일반적으로 리소스 하드웨어 토폴로지 탐지를 실행하지만 CR 요청은 nfd-master로 전송되지 않습니다.
기본값: false
예제
$ nfd-topology-updater -no-publish
4.5.2.1. -oneshot
-oneshot
플래그를 사용하면 NFD Topology Updater가 리소스 하드웨어 토폴로지 탐지 중 하나를 통과한 후 종료됩니다.
기본값: false
예제
$ nfd-topology-updater -oneshot -no-publish
-podresources-socket
-podresources-socket
플래그는 kubelet이 사용 중인 CPU 및 장치를 검색할 수 있도록 gRPC 서비스를 내보내고 해당 장치에 대한 메타데이터를 제공하는 Unix 소켓의 경로를 지정합니다.
기본값: /host-var/liblib/kubelet/pod-resources/kubelet.sock
예제
$ nfd-topology-updater -podresources-socket=/var/lib/kubelet/pod-resources/kubelet.sock
-server
server
플래그는 연결할 nfd-master 엔드포인트의 주소를 지정합니다.
기본값: localhost:8080
예제
$ nfd-topology-updater -server=nfd-master.nfd.svc.cluster.local:443
-server-name-override
server-name-override
플래그는 nfd-master TLS 인증서에서 기대할 수 있는 CN(일반 이름)을 지정합니다. 이 플래그는 대부분 개발 및 디버깅 목적으로 사용됩니다.
기본값: empty
예제
$ nfd-topology-updater -server-name-override=localhost
-sleep-interval
-sleep-interval
플래그는 리소스 하드웨어 토폴로지 재검사 및 사용자 정의 리소스 업데이트 간의 간격을 지정합니다. 양수가 아닌 값은 무한 절전 간격을 의미하며 재검색이 수행되지 않습니다.
기본값: 60s
예제
$ nfd-topology-updater -sleep-interval=1h
-version
버전을 출력하고 종료합니다.
-watch-namespace
-watch-namespace
플래그는 지정된 네임스페이스에서 실행 중인 Pod에서만 리소스 하드웨어 토폴로지 검사만 수행할 수 있도록 네임스페이스를 지정합니다. 지정된 네임스페이스에서 실행되지 않는 Pod는 리소스 회계 중에 고려되지 않습니다. 이는 테스트 및 디버깅 목적에 특히 유용합니다. *
값은 모든 네임스페이스의 모든 Pod가 회계 프로세스 중에 고려됨을 의미합니다.
기본값: *
예제
$ nfd-topology-updater -watch-namespace=rte
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.