Red Hat Summit2장. 베어 메탈에 OpenShift 샌드박스 컨테이너 배포
작업자 노드에 RHCOS(Red Hat Enterprise Linux CoreOS)가 설치된 온프레미스 베어 메탈 클러스터에 OpenShift 샌드박스 컨테이너를 배포할 수 있습니다.
- RHEL 노드는 지원되지 않습니다.
- 중첩된 가상화는 지원되지 않습니다.
사용자 프로비저닝 , 설치 관리자 프로비저닝 또는 지원설치 프로그램을 포함하여 설치 방법을 사용하여 클러스터를 배포할 수 있습니다.
AWS(Amazon Web Services) 베어 메탈 인스턴스에 OpenShift 샌드박스 컨테이너를 설치할 수도 있습니다. 다른 클라우드 공급자가 제공하는 베어 메탈 인스턴스는 지원되지 않습니다.
클러스터 요구 사항
- OpenShift 샌드박스 컨테이너 Operator를 설치하는 클러스터에 Red Hat OpenShift Container Platform 4.14 이상을 설치했습니다.
- 클러스터에 작업자 노드가 하나 이상 있습니다.
베어 메탈에 OpenShift Container Platform을 설치하는 방법에 대한 자세한 내용은 베어 메탈에 설치를 참조하십시오.
2.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에 불과하며 3개의 다른 위치에 매핑됩니다. 이는 메모리 사용량 메트릭을 보고할 때 올바르게 계산됩니다.
