2.3. 명령줄을 사용하여 OpenShift 샌드박스 컨테이너 배포
CLI(명령줄 인터페이스)를 사용하여 다음 작업을 수행하여 베어 메탈에 OpenShift 샌드박스 컨테이너를 배포할 수 있습니다.
- OpenShift 샌드박스 컨테이너 Operator를 설치합니다.
Operator를 설치한 후 다음 옵션을 구성할 수 있습니다.
- 블록 스토리지 장치를 구성합니다.
NFD(Node Feature Discovery) Operator를 설치하여 노드 자격 검사를 구성합니다. 자세한 내용은 노드 자격 검사 및 NFD Operator 설명서를 참조하십시오.
-
NodeFeatureDiscovery
사용자 정의 리소스를 생성합니다.
-
-
KataConfig
사용자 지정 리소스를 생성합니다. - 선택 사항: Pod 오버헤드를 수정합니다.
- OpenShift 샌드박스 컨테이너 워크로드 오브젝트를 구성합니다.
2.3.1. OpenShift 샌드박스 컨테이너 Operator 설치
CLI를 사용하여 OpenShift 샌드박스 컨테이너 Operator를 설치할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
osc-namespace.yaml
매니페스트 파일을 생성합니다.apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
다음 명령을 실행하여 네임스페이스를 생성합니다.
$ oc apply -f osc-namespace.yaml
osc-operatorgroup.yaml
매니페스트 파일을 생성합니다.apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: sandboxed-containers-operator-group namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operator
다음 명령을 실행하여 operator 그룹을 생성합니다.
$ oc apply -f osc-operatorgroup.yaml
osc-subscription.yaml
매니페스트 파일을 생성합니다.apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: channel: stable installPlanApproval: Automatic name: sandboxed-containers-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: sandboxed-containers-operator.v1.8.0
다음 명령을 실행하여 서브스크립션을 생성합니다.
$ oc apply -f osc-subscription.yaml
다음 명령을 실행하여 Operator가 올바르게 설치되었는지 확인합니다.
$ oc get csv -n openshift-sandboxed-containers-operator
이 명령을 완료하는 데 몇 분이 걸릴 수 있습니다.
다음 명령을 실행하여 프로세스를 확인합니다.
$ watch oc get csv -n openshift-sandboxed-containers-operator
출력 예
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.8.0 1.7.0 Succeeded
추가 리소스
2.3.2. 선택적 구성
OpenShift 샌드박스 컨테이너 Operator를 설치한 후 다음 옵션을 구성할 수 있습니다.
2.3.2.1. 로컬 블록 볼륨 프로비저닝
OpenShift 샌드박스 컨테이너와 함께 로컬 블록 볼륨을 사용할 수 있습니다. 먼저 LSO(Local Storage Operator)를 사용하여 로컬 블록 볼륨을 프로비저닝해야 합니다. 그런 다음 로컬 블록 볼륨이 있는 노드를 활성화해야 OpenShift 샌드박스 컨테이너 워크로드를 실행해야 합니다.
LSO(Local Storage Operator)를 사용하여 OpenShift 샌드박스 컨테이너의 로컬 블록 볼륨을 프로비저닝할 수 있습니다. 로컬 볼륨 프로비저너는 정의된 리소스에 지정된 경로에서 블록 볼륨 장치를 찾습니다.
사전 요구 사항
- Local Storage Operator가 설치되어 있습니다.
다음 조건을 충족하는 로컬 디스크가 있습니다.
- 노드에 연결되어 있습니다.
- 마운트되지 않았습니다.
- 파티션이 포함되어 있지 않습니다.
프로세스
로컬 볼륨 리소스를 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.
참고동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 PV(영구 볼륨)가 생성됩니다.
예: 블록
apiVersion: "local.storage.openshift.io/v1" kind: "LocalVolume" metadata: name: "local-disks" namespace: "openshift-local-storage" 1 spec: nodeSelector: 2 nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - ip-10-0-136-143 - ip-10-0-140-255 - ip-10-0-144-180 storageClassDevices: - storageClassName: "local-sc" 3 forceWipeDevicesAndDestroyAllData: false 4 volumeMode: Block devicePaths: 5 - /path/to/device 6
- 1
- Local Storage Operator가 설치된 네임스페이스입니다.
- 2
- 선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는
oc get node
에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다. - 3
- 영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다.
- 4
- 이 설정은
wipefs
를 호출할지 여부를 정의합니다. 즉, 파티션 테이블 서명(마이크 문자열)을 제거하여 Local Storage Operator 프로비저닝에 디스크를 사용할 준비가 되었습니다. 서명 이외의 다른 데이터는 삭제되지 않습니다. 기본값은 "false"입니다(wipefs
가 호출되지 않음).forceWipeDevicesAndDestroyAllData
를 "true"로 설정하면 이전 데이터를 다시 사용해야 하는 디스크에 남아 있을 수 있는 시나리오에서 유용할 수 있습니다. 이러한 시나리오에서는 이 필드를 true로 설정하면 관리자가 디스크를 수동으로 지울 필요가 없습니다. - 5
- 선택할 로컬 스토리지 장치 목록이 포함된 경로입니다. 로컬 블록 장치가 있는 노드를 활성화하여 OpenShift 샌드박스 컨테이너 워크로드를 실행할 때 이 경로를 사용해야 합니다.
- 6
- 이 값을
LocalVolume
리소스의 filepath로 바꿉니다(예:/dev/disk/
). 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.by-id
/wwn
OpenShift Container Platform 클러스터에 로컬 볼륨 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.
$ oc apply -f <local-volume>.yaml
프로비저너가 생성되었고 해당 데몬 세트가 생성되었는지 확인합니다.
$ oc get all -n openshift-local-storage
출력 예
NAME READY STATUS RESTARTS AGE pod/diskmaker-manager-9wzms 1/1 Running 0 5m43s pod/diskmaker-manager-jgvjp 1/1 Running 0 5m43s pod/diskmaker-manager-tbdsj 1/1 Running 0 5m43s pod/local-storage-operator-7db4bd9f79-t6k87 1/1 Running 0 14m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/local-storage-operator-metrics ClusterIP 172.30.135.36 <none> 8383/TCP,8686/TCP 14m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/diskmaker-manager 3 3 3 3 3 <none> 5m43s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/local-storage-operator 1/1 1 1 14m NAME DESIRED CURRENT READY AGE replicaset.apps/local-storage-operator-7db4bd9f79 1 1 1 14m
원하는
데몬 세트 프로세스 및현재
개수를 기록해 둡니다.원하는
개수가0
이면 라벨 선택기가 유효하지 않음을 나타냅니다.영구 볼륨이 생성되었는지 확인합니다.
$ oc get pv
출력 예
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE local-pv-1cec77cf 100Gi RWO Delete Available local-sc 88m local-pv-2ef7cd2a 100Gi RWO Delete Available local-sc 82m local-pv-3fa1c73 100Gi RWO Delete Available local-sc 48m
LocalVolume
오브젝트를 편집해도 안전하지 않은 작업이 발생할 수 있으므로 기존 영구 볼륨이 변경되지 않습니다.
2.3.2.2. 노드가 로컬 블록 장치를 사용하도록 활성화
로컬 블록 장치로 노드를 구성하여 정의된 볼륨 리소스에 지정된 경로에서 OpenShift 샌드박스 컨테이너 워크로드를 실행할 수 있습니다.
사전 요구 사항
- LSO(Local Storage Operator)를 사용하여 블록 장치를 프로비저닝합니다.
프로세스
로컬 블록 장치가 있는 각 노드를 활성화하여 다음 명령을 실행하여 OpenShift 샌드박스 컨테이너 워크로드를 실행합니다.
$ oc debug node/worker-0 -- chcon -vt container_file_t /host/path/to/device
/path/to/device
는 로컬 스토리지 리소스를 생성할 때 정의한 경로와 동일해야 합니다.출력 예
system_u:object_r:container_file_t:s0 /host/path/to/device
2.3.2.3. NodeFeatureDiscovery 사용자 정의 리소스 생성
NodeFeatureDiscovery
CR(사용자 정의 리소스)을 생성하여 NFD(Node Feature Discovery) Operator에서 작업자 노드에서 OpenShift 샌드박스 컨테이너를 지원할 수 있는지 확인하는 구성 매개변수를 정의합니다.
사용자가 알고 있는 선택된 작업자 노드에만 kata
런타임을 설치하려면 feature.node.kubernetes.io/runtime.kata=true
레이블을 선택한 노드에 적용하고 KataConfig
CR에서 checkNodeEligibility: true
를 설정합니다.
모든 작업자 노드에 kata
런타임을 설치하려면 KataConfig
CR에 checkNodeEligibility: false
를 설정합니다.
이러한 두 시나리오에서는 NodeFeatureDiscovery
CR을 생성할 필요가 없습니다. 노드가 OpenShift 샌드박스 컨테이너를 실행할 수 있는지 확인하는 경우 feature.node.kubernetes.io/runtime.kata=true
레이블만 수동으로 적용해야 합니다.
다음 절차에서는 feature.node.kubernetes.io/runtime.kata=true
레이블을 모든 적격 노드에 적용하고 노드 자격을 확인하도록 KataConfig
리소스를 구성합니다.
사전 요구 사항
- NFD Operator가 설치되어 있습니다.
프로세스
다음 예에 따라
nfd.yaml
매니페스트 파일을 생성합니다.apiVersion: nfd.openshift.io/v1 kind: NodeFeatureDiscovery metadata: name: nfd-kata namespace: openshift-nfd spec: workerConfig: configData: | sources: custom: - name: "feature.node.kubernetes.io/runtime.kata" matchOn: - cpuId: ["SSE4", "VMX"] loadedKMod: ["kvm", "kvm_intel"] - cpuId: ["SSE4", "SVM"] loadedKMod: ["kvm", "kvm_amd"] # ...
NodeFeatureDiscovery
CR을 생성합니다.$ oc create -f nfd.yaml
NodeFeatureDiscovery
CR은feature.node.kubernetes.io/runtime.kata=true
레이블을 모든 적격 작업자 노드에 적용합니다.
다음 예에 따라
kata-config.yaml
매니페스트 파일을 생성합니다.apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
KataConfig
CR을 생성합니다.$ oc create -f kata-config.yaml
검증
클러스터의 적격한 노드에 올바른 레이블이 적용되었는지 확인합니다.
$ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'
출력 예
NAME STATUS ROLES AGE VERSION compute-3.example.com Ready worker 4h38m v1.25.0 compute-2.example.com Ready worker 4h35m v1.25.0
2.3.3. KataConfig 사용자 지정 리소스 생성
작업자 노드에 kata
를 런타임 클래스로 설치하려면 KataConfig
CR(사용자 정의 리소스)을 생성해야 합니다.
KataConfig
CR을 생성하면 OpenShift 샌드박스 컨테이너 Operator가 다음을 수행합니다.
-
RHCOS 노드에 QEMU 및
kata-containers
와 같은 필요한 RHCOS 확장을 설치합니다. - CRI-O 런타임이 올바른 런타임 처리기로 구성되었는지 확인합니다.
-
기본 구성으로
kata
라는RuntimeClass
CR을 생성합니다. 이를 통해 사용자는RuntimeClassName
필드에서 CR을 참조하여kata
를 런타임으로 사용하도록 워크로드를 구성할 수 있습니다. 이 CR은 런타임의 리소스 오버헤드도 지정합니다.
OpenShift 샌드박스 컨테이너는 kata
를 기본 런타임이 아닌 클러스터의 선택적 런타임으로 설치합니다.
KataConfig
CR을 생성하면 작업자 노드가 자동으로 재부팅됩니다. 재부팅에는 10분에서 60분 이상 걸릴 수 있습니다. 재부팅 시간을 방해하는 요소는 다음과 같습니다.
- 더 많은 작업자 노드가 있는 대규모 OpenShift Container Platform 배포
- BIOS 및 Cryostat 유틸리티 활성화.
- SSD가 아닌 하드 디스크 드라이브에 배포합니다.
- 가상 노드가 아닌 베어 메탈과 같은 물리적 노드에 배포됩니다.
- 느린 CPU 및 네트워크입니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 선택 사항: 노드 자격 검사를 활성화하려면 Node Feature Discovery Operator를 설치했습니다.
프로세스
다음 예에 따라
example-kataconfig.yaml
매니페스트 파일을 생성합니다.apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: false 1 logLevel: info # kataConfigPoolSelector: # matchLabels: # <label_key>: '<label_value>' 2
다음 명령을 실행하여
KataConfig
CR을 생성합니다.$ oc apply -f example-kataconfig.yaml
새로운
KataConfig
CR이 생성되고 작업자 노드에kata
를 런타임 클래스로 설치합니다.kata
설치가 완료되고 설치를 확인하기 전에 작업자 노드가 재부팅될 때까지 기다립니다.다음 명령을 실행하여 설치 진행 상황을 모니터링합니다.
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
kataNodes
아래의 모든 작업자의 상태가설치되고
이유를 지정하지 않고InProgress
조건이False
이면 클러스터에kata
가 설치됩니다.
2.3.4. Pod 오버헤드 수정
Pod 오버헤드는 노드의 Pod에서 사용하는 시스템 리소스의 양을 설명합니다. RuntimeClass
사용자 정의 리소스의 spec.overhead
필드를 변경하여 Pod 오버헤드를 수정할 수 있습니다. 예를 들어 컨테이너에 대해 실행하는 구성이 QEMU 프로세스 및 게스트 커널 데이터에 350Mi 이상의 메모리를 사용하는 경우 필요에 맞게 RuntimeClass
오버헤드를 변경할 수 있습니다.
게스트에서 모든 유형의 파일 시스템 I/O를 수행할 때 게스트 커널에 파일 버퍼가 할당됩니다. 파일 버퍼는 virtiofsd
프로세스뿐만 아니라 호스트의 QEMU 프로세스에도 매핑됩니다.
예를 들어 게스트에서 300Mi 파일 버퍼 캐시를 사용하는 경우 QEMU와 virtiofsd
는 모두 300Mi 추가 메모리를 사용하는 것처럼 나타납니다. 그러나 세 가지 경우 모두 동일한 메모리가 사용됩니다. 따라서 총 메모리 사용량은 300Mi에 불과하며 3개의 다른 위치에 매핑됩니다. 이는 메모리 사용량 메트릭을 보고할 때 올바르게 계산됩니다.
기본값은 Red Hat에서 지원합니다. 기본 오버헤드 값 변경은 지원되지 않으며 값을 변경하면 기술적인 문제가 발생할 수 있습니다.
프로세스
다음 명령을 실행하여
RuntimeClass
오브젝트를 가져옵니다.$ oc describe runtimeclass kata
overhead.podFixed.memory
및cpu
값을 업데이트하고 파일로runtimeclass.yaml
로 저장합니다.kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata overhead: podFixed: memory: "500Mi" cpu: "500m"
다음 명령을 실행하여 변경 사항을 적용합니다.
$ oc apply -f runtimeclass.yaml
2.3.5. 워크로드 오브젝트 구성
kata
를 다음 pod 템플릿 오브젝트의 런타임 클래스로 설정하여 OpenShift 샌드박스 컨테이너 워크로드 오브젝트를 구성해야 합니다.
-
Pod
오브젝트 -
ReplicaSet
오브젝트 -
ReplicationController
오브젝트 -
StatefulSet
오브젝트 -
Deployment
오브젝트 -
DeploymentConfig
오브젝트
Operator 네임스페이스에 워크로드를 배포하지 마십시오. 이러한 리소스에 대한 전용 네임스페이스를 생성합니다.
사전 요구 사항
-
KataConfig
CR(사용자 정의 리소스)을 생성했습니다.
프로세스
다음 예와 같이
spec.runtimeClassName: kata
를 각 pod 템플릿 워크로드 오브젝트의 매니페스트에 추가합니다.apiVersion: v1 kind: <object> # ... spec: runtimeClassName: kata # ...
OpenShift Container Platform은 워크로드 오브젝트를 생성하고 스케줄링을 시작합니다.
검증
-
pod-templated 오브젝트의
spec.runtimeClassName
필드를 검사합니다. 값이kata
이면 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너에서 워크로드가 실행됩니다.