2장. OpenShift 샌드박스 컨테이너 워크로드 배포
웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 OpenShift 샌드박스 컨테이너 Operator를 설치할 수 있습니다. OpenShift 샌드박스 컨테이너 Operator를 설치하기 전에 OpenShift Container Platform 클러스터를 준비해야 합니다.
2.1. 사전 요구 사항
OpenShift 샌드박스 컨테이너를 설치하기 전에 OpenShift Container Platform 클러스터가 다음 요구 사항을 충족하는지 확인하십시오.
RHCOS(Red Hat Enterprise Linux CoreOS) 작업자가 있는 온프레미스 베어 메탈 인프라에 클러스터가 설치되어 있어야 합니다. 사용자 프로비저닝, 설치 관리자 프로비저닝 또는 지원 설치 프로그램을 포함하여 설치 방법을 사용하여 클러스터를 배포할 수 있습니다.
참고- OpenShift 샌드박스 컨테이너는 RHCOS 작업자 노드만 지원합니다. RHEL 노드는 지원되지 않습니다.
- 중첩된 가상화는 지원되지 않습니다.
- AWS(Amazon Web Services) 베어 메탈 인스턴스에 OpenShift 샌드박스 컨테이너를 설치할 수 있습니다. 다른 클라우드 공급자가 제공하는 베어 메탈 인스턴스는 지원되지 않습니다.
2.1.1. OpenShift 샌드박스 컨테이너의 리소스 요구 사항
OpenShift 샌드박스 컨테이너를 사용하면 사용자가 샌드박스 런타임(Kata) 내의 OpenShift Container Platform 클러스터에서 워크로드를 실행할 수 있습니다. 각 Pod는 VM(가상 머신)으로 표시됩니다. 각 VM은 QEMU 프로세스에서 실행되며 컨테이너 워크로드를 관리하기 위한 감독자 역할을 하는 kata-agent 프로세스 및 해당 컨테이너에서 실행되는 프로세스를 호스팅합니다. 두 개의 추가 프로세스는 오버헤드를 더 추가합니다.
-
containerd-shim-kata-v2는 pod와 통신하는 데 사용됩니다. -
virtiofsd는 게스트 대신 호스트 파일 시스템 액세스를 처리합니다.
각 VM은 기본 메모리 양으로 구성됩니다. 메모리를 명시적으로 요청하는 컨테이너의 경우 VM에 추가 메모리가 핫플러그됩니다.
메모리 리소스 없이 실행되는 컨테이너는 VM에서 사용하는 총 메모리가 기본 할당에 도달할 때까지 사용 가능한 메모리를 사용합니다. 게스트와 I/O 버퍼도 메모리를 소비합니다.
컨테이너에 특정 양의 메모리가 제공되면 컨테이너를 시작하기 전에 해당 메모리는 VM에 핫플러그됩니다.
메모리 제한을 지정하면 제한보다 많은 메모리를 사용하는 경우 워크로드가 종료됩니다. 메모리 제한을 지정하지 않으면 VM에서 실행 중인 커널이 메모리 부족을 실행할 수 있습니다. 커널이 메모리 부족하면 VM의 다른 프로세스를 종료할 수 있습니다.
기본 메모리 크기
다음 표에는 리소스 할당에 대한 기본값이 나열되어 있습니다.
| 리소스 | 현재의 |
|---|---|
| 기본적으로 가상 머신에 할당된 메모리 | 2Gi |
| 부팅 시 게스트 Linux 커널 메모리 사용량 | ~110Mi |
| QEMU 프로세스에서 사용하는 메모리 (VM 메모리 제외) | ~30Mi |
|
| ~10Mi |
|
| ~20Mi |
|
Fedora에서 | ~300Mi* [1] |
파일 버퍼가 나타나고 다음과 같은 여러 위치에서 고려됩니다.
- 게스트에서 파일 버퍼 캐시로 표시
-
허용된 사용자 공간 파일 I/O 작업을 매핑된
virtiofsd데몬 - 게스트 메모리로 사용되는 QEMU 프로세스
총 메모리 사용량은 메모리 사용량 통계에 따라 적절히 계산되며, 이 메트릭은 해당 메모리를 한 번만 계산합니다.
Pod 오버헤드는 노드의 Pod에서 사용하는 시스템 리소스의 양을 설명합니다. 다음과 같이 oc describe runtimeclass kata 를 사용하여 Kata 런타임에 대한 현재 Pod 오버헤드를 가져올 수 있습니다.
예제
$ oc describe runtimeclass kata
출력 예
kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
name: kata
overhead:
podFixed:
memory: "500Mi"
cpu: "500m"
RuntimeClass의 spec.overhead 필드를 변경하여 Pod 오버헤드를 변경할 수 있습니다. 예를 들어 컨테이너에 대해 실행하는 구성이 QEMU 프로세스 및 게스트 커널 데이터에 350Mi 이상의 메모리를 사용하는 경우 필요에 맞게 RuntimeClass 오버헤드를 변경할 수 있습니다.
Red Hat은 지정된 기본 오버헤드 값을 지원합니다. 기본 오버헤드 값 변경은 지원되지 않으며 값을 변경하면 기술적인 문제가 발생할 수 있습니다.
게스트에서 모든 유형의 파일 시스템 I/O를 수행할 때 게스트 커널에 파일 버퍼가 할당됩니다. 파일 버퍼는 virtiofsd 프로세스뿐만 아니라 호스트의 QEMU 프로세스에도 매핑됩니다.
예를 들어 게스트에서 300Mi 파일 버퍼 캐시를 사용하는 경우 QEMU와 virtiofsd는 모두 300Mi 추가 메모리를 사용하는 것처럼 나타납니다. 그러나 세 가지 경우 모두 동일한 메모리가 사용됩니다. 즉, 총 메모리 사용량은 300Mi에 불과하며 이 값은 서로 다른 세 위치에 매핑됩니다. 이는 메모리 사용량 메트릭을 보고할 때 올바르게 계산됩니다.
추가 리소스
2.1.2. 클러스터 노드가 OpenShift 샌드박스 컨테이너를 실행할 수 있는지 확인
OpenShift 샌드박스 컨테이너를 실행하기 전에 클러스터의 노드가 Kata 컨테이너를 실행할 수 있는지 확인할 수 있습니다. 일부 클러스터 노드는 샌드박스 컨테이너의 최소 요구 사항을 준수하지 않을 수 있습니다. 노드 자격에 대한 가장 일반적인 이유는 노드에서 가상화 지원이 부족하기 때문입니다. 자격 없는 노드에서 샌드박스 워크로드를 실행하려고 하면 오류가 발생합니다. NFD(Node Feature Discovery) Operator 및 NodeFeatureDiscovery 리소스를 사용하여 노드 자격을 자동으로 확인할 수 있습니다.
사용자가 알고 있는 선택된 작업자 노드에 Kata 런타임을 설치하려면 feature.node.kubernetes.io/runtime.kata=true 레이블을 선택한 노드에 적용하고 KataConfig 리소스에서 checkNodeEligibility: true 를 설정합니다.
또는 모든 작업자 노드에 Kata 런타임을 설치하려면 KataConfig 리소스에서 checkNodeEligibility: false 를 설정합니다.
이러한 두 시나리오에서는 NodeFeatureDiscovery 리소스를 생성할 필요가 없습니다. 노드가 Kata 컨테이너를 실행할 수 있는지 확인하는 경우 feature.node.kubernetes.io/runtime.kata=true 레이블만 수동으로 적용해야 합니다.
다음 절차에서는 feature.node.kubernetes.io/runtime.kata=true 레이블을 모든 적격 노드에 적용하고 노드 자격을 확인하도록 KataConfig 리소스를 구성합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다. - NFD(Node Feature Discovery) Operator를 설치합니다.
프로세스
NodeFeatureDiscovery리소스를 생성하여 Kata 컨테이너 실행에 적합한 노드 기능을 감지합니다.nfd.yaml파일에 다음 YAML을 저장합니다.apiVersion: nfd.openshift.io/v1 kind: NodeFeatureDiscovery metadata: name: nfd-kata namespace: openshift-nfd spec: operand: image: quay.io/openshift/origin-node-feature-discovery:4.10 imagePullPolicy: Always servicePort: 12000 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"]NodeFeatureDiscoveryCR(사용자 정의 리소스)을 생성합니다.$ oc create -f nfd.yaml
출력 예
nodefeaturediscovery.nfd.openshift.io/nfd-kata created
feature.node.kubernetes.io/runtime.kata=true레이블이 모든 적격 작업자 노드에 적용됩니다.
기능을 활성화하려면
KataConfig리소스에서checkNodeEligibility필드를true로 설정합니다. 예를 들면 다음과 같습니다.다음 YAML을
kata-config.yaml파일에 저장합니다.apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: true
KataConfigCR을 생성합니다.$ oc create -f kata-config.yaml
출력 예
kataconfig.kataconfiguration.openshift.io/example-kataconfig created
검증
클러스터의 적격한 노드에 올바른 레이블이 적용되었는지 확인합니다.
$ 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
추가 리소스
- NFD(Node Feature Discovery) Operator 설치에 대한 자세한 내용은 NFD 설치를 참조하십시오.
