Red Hat Summit3장. OpenShift 샌드박스 컨테이너 워크로드 배포
웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 OpenShift 샌드박스 컨테이너 Operator를 설치할 수 있습니다. OpenShift 샌드박스 컨테이너 Operator를 설치하기 전에 OpenShift Container Platform 클러스터를 준비해야 합니다.
3.1. OpenShift 샌드박스 컨테이너용 클러스터 준비
OpenShift 샌드박스 컨테이너를 설치하기 전에 OpenShift Container Platform 클러스터가 다음 요구 사항을 충족하는지 확인하십시오.
Red Hat Enterprise Linux CoreOS(RHCOS) 작업자가 있는 베어 메탈 인프라에 클러스터가 설치되어 있어야 합니다. 클러스터는 설치 프로그램이 프로비저닝한 인프라를 사용해야 합니다.
중요- OpenShift 샌드박스 컨테이너는 RHCOS 작업자 노드만 지원합니다. RHEL 7 또는 RHEL 8 노드는 지원되지 않습니다.
- 중첩된 가상화는 지원되지 않습니다.
3.1.1. OpenShift 샌드박스 컨테이너에 대한 기타 리소스 요구 사항
OpenShift 샌드박스 컨테이너는 Kata Containers와 같은 샌드박스 런타임 내에서 OpenShift Container Platform 클러스터에 대한 워크로드를 실행할 수 있는 제품입니다. 각 Pod는 VM(가상 머신)으로 표시됩니다. 각 VM은 qemu 프로세스에서 실행되며 해당 컨테이너에서 실행 중인 컨테이너 워크로드 및 프로세스를 관리하기 위한 감독자 역할을 하는 kata-agent 프로세스를 호스팅합니다. 오버헤드를 증가시키는 두 개의 추가 프로세스가 있습니다.
-
containerd-shim-kata-v2는 pod와 통신하는 데 사용됩니다. -
virtiofsd는 게스트 대신 호스트 파일 시스템 액세스를 처리합니다.
각 VM은 기본 메모리 양으로 구성됩니다. 메모리를 명시적으로 요청하는 컨테이너의 경우 VM에 추가 메모리가 핫플러그됩니다.
- 지정된 메모리 리소스 없이 컨테이너가 실행되면 사용 가능한 메모리를 사용할 수 있습니다. VM에서 사용하는 총 메모리가 기본 할당에 도달할 때까지 이 작업을 수행합니다. 게스트와 I/O 버퍼도 메모리를 소비합니다.
- 컨테이너에 특정 양의 메모리가 제공되면 컨테이너를 시작하기 전에 해당 메모리는 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
출력 예
Name: kata
[...]
Metadata:
[...]
Overhead:
Pod Fixed:
Cpu: 250m
Memory: 350Mi
[...]
RuntimeClass의 spec.overhead 필드를 변경하여 Pod 오버헤드를 변경할 수 있습니다. 예를 들어 컨테이너에 대한 구성이 QEMU 프로세스 및 게스트 커널 데이터에 대해 350Mi 이상의 메모리를 사용하는 경우 필요에 맞게 RuntimeClass 오버헤드를 변경할 수 있습니다.
Red Hat은 지정된 기본 오버헤드 값을 지원합니다. 기본 오버헤드 값 변경은 지원되지 않으며 값을 변경하면 기술적인 문제가 발생할 수 있습니다.
예제
kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
name: kata
overhead:
podFixed:
memory: "500Mi"
cpu: "500m"
- 가상 시스템의 기본 할당은 2Gi입니다.
- Linux 커널은 부팅 시 약 100Mi의 메모리를 사용합니다.
- QEMU 프로세스는 약 30Mi 의 메모리를 사용합니다.
-
virtiofsd프로세스는 약 10Mi의 메모리를 사용합니다. -
shim-v2프로세스는 약 20Mi 메모리를 사용합니다.
게스트에서 모든 유형의 파일 시스템 I/O를 수행할 때 게스트 커널에 파일 버퍼가 할당됩니다. 파일 버퍼는 호스트의 QEMU 프로세스 및 virtiofsd 프로세스에도 매핑됩니다. 예를 들어 게스트에서 300Mi 파일 버퍼 캐시를 사용하는 경우 QEMU와 virtiofsd는 모두 300Mi 추가 메모리를 사용하는 것처럼 나타납니다. 그러나 세 가지 경우 모두 동일한 메모리가 사용됩니다. 즉, 총 메모리 사용량은 300Mi에 불과하며 이 값은 서로 다른 세 위치에 매핑됩니다. 이는 메모리 사용량 메트릭을 보고할 때 올바르게 계산됩니다.
