5.11. 노드 수준 오버 커밋
QoS (Quality of Service) 보장, CPU 제한 또는 리소스 예약과 같은 다양한 방법으로 특정 노드에서 오버 커밋을 제어할 수 있습니다. 특정 노드 및 특정 프로젝트의 오버 커밋을 비활성화할 수도 있습니다.
5.11.1. 컴퓨팅 리소스 및 컨테이너 이해
컴퓨팅 리소스에 대한 노드 적용 동작은 리소스 유형에 따라 다릅니다.
5.11.1.1. 컨테이너의 CPU 요구 이해
컨테이너에 요청된 CPU의 양이 보장되며 컨테이너에서 지정한 한도까지 노드에서 사용 가능한 초과 CPU를 추가로 소비할 수 있습니다. 여러 컨테이너가 초과 CPU를 사용하려고하면 각 컨테이너에서 요청된 CPU 양에 따라 CPU 시간이 분배됩니다.
예를 들어, 한 컨테이너가 500m의 CPU 시간을 요청하고 다른 컨테이너가 250m의 CPU 시간을 요청한 경우 노드에서 사용 가능한 추가 CPU 시간이 2:1 비율로 컨테이너간에 분배됩니다. 컨테이너가 제한을 지정한 경우 지정된 한도를 초과하는 많은 CPU를 사용하지 않도록 제한됩니다. CPU 요청은 Linux 커널에서 CFS 공유 지원을 사용하여 적용됩니다. 기본적으로 CPU 제한은 Linux 커널에서 CFS 할당량 지원을 사용하여 100ms 측정 간격으로 적용되지만 이 기능은 비활성화할 수 있습니다.
5.11.1.2. 컨테이너의 메모리 요구 이해
컨테이너에 요청된 메모리 양이 보장됩니다. 컨테이너는 요청된 메모리보다 많은 메모리를 사용할 수 있지만 요청된 양을 초과하면 노드의 메모리 부족 상태에서 종료될 수 있습니다. 컨테이너가 요청된 메모리보다 적은 메모리를 사용하는 경우 시스템 작업 또는 데몬이 노드의 리소스 예약에 확보된 메모리 보다 더 많은 메모리를 필요로하지 않는 한 컨테이너는 종료되지 않습니다. 컨테이너가 메모리 제한을 지정할 경우 제한 양을 초과하면 즉시 종료됩니다.
5.11.2. 과다 할당 및 서비스 품질 클래스 이해
요청이 없는 pod가 예약되어 있거나 해당 노드의 모든 pod에서 제한의 합계가 사용 가능한 머신 용량을 초과하면 노드가 오버 커밋됩니다.
오버 커밋된 환경에서는 노드의 pod가 특정 시점에서 사용 가능한 것보다 더 많은 컴퓨팅 리소스를 사용하려고 할 수 있습니다. 이 경우 노드는 각 pod에 우선 순위를 지정해야합니다. 이러한 결정을 내리는 데 사용되는 기능을 QoS (Quality of Service) 클래스라고 합니다.
Pod는 우선순위 순서가 감소된 세 가지 QoS 클래스 중 하나로 지정됩니다.
| 우선 순위 | 클래스 이름 | 설명 |
|---|---|---|
| 1 (가장 높음) | Guaranteed | 모든 리소스에 대해 제한 및 요청(선택 사항)이 설정되고 (0과 같지 않음) Pod는 Guaranteed 로 분류됩니다. |
| 2 | Burstable | 모든 리소스에 대해 요청 및 제한(선택 사항)이 설정되고 (0과 같지 않음) Pod는 Burstable 로 분류됩니다. |
| 3 (가장 낮음) | BestEffort | 리소스에 대해 요청 및 제한이 설정되지 않은 경우 Pod는 BestEffort 로 분류됩니다. |
메모리는 압축할 수 없는 리소스이므로 메모리가 부족한 경우 우선 순위가 가장 낮은 컨테이너가 먼저 종료됩니다.
- Guaranteed 컨테이너는 우선 순위가 가장 높은 컨테이너로 간주되며 제한을 초과하거나 시스템의 메모리가 부족하고 제거할 수 있는 우선 순위가 낮은 컨테이너가 없는 경우에만 종료됩니다.
- 시스템 메모리 부족 상태에 있는 Burstable 컨테이너는 제한을 초과하고 다른 BestEffort 컨테이너가 없으면 종료될 수 있습니다.
- BestEffort 컨테이너는 우선 순위가 가장 낮은 컨테이너로 처리됩니다. 시스템에 메모리가 부족한 경우 이러한 컨테이너의 프로세스가 먼저 종료됩니다.
5.11.2.1. Quality of Service (QoS) 계층에서 메모리 예약 방법
qos-reserved 매개변수를 사용하여 특정 QoS 수준에서 pod에 예약된 메모리의 백분율을 지정할 수 있습니다. 이 기능은 요청된 리소스를 예약하여 하위 OoS 클래스의 pod가 고급 QoS 클래스의 pod에서 요청한 리소스를 사용하지 못하도록 합니다.
OpenShift Container Platform은 다음과 같이 qos-reserved 매개변수를 사용합니다.
-
qos-reserved=memory=100%값은Burstable및BestEffortQoS 클래스가 더 높은 QoS 클래스에서 요청한 메모리를 소비하지 못하도록 합니다. 이를 통해BestEffort및Burstable워크로드에서 OOM이 발생할 위험이 증가되어Guaranteed및Burstable워크로드에 대한 메모리 리소스의 보장 수준을 높이는 것이 우선됩니다. -
qos-reserved=memory=50%값은Burstable및BestEffortQoS 클래스가 더 높은 QoS 클래스에서 요청한 메모리의 절반을 소비하는 것을 허용합니다. -
qos-reserved=memory=0%값은Burstable및BestEffortQoS 클래스가 사용 가능한 경우 할당 가능한 최대 노드 양까지 소비하는 것을 허용하지만Guaranteed워크로드가 요청된 메모리에 액세스하지 못할 위험이 높아집니다. 이로 인해 이 기능은 비활성화되어 있습니다.
5.11.3. 스왑 메모리 및 QOS 이해
QoS (Quality of Service) 보장을 유지하기 위해 노드에서 기본적으로 스왑을 비활성화할 수 있습니다. 그렇지 않으면 노드의 물리적 리소스를 초과 구독하여 Pod 배포 중에 Kubernetes 스케줄러가 만드는 리소스에 영향을 미칠 수 있습니다.
예를 들어 2 개의 Guaranteed pod가 메모리 제한에 도달하면 각 컨테이너가 스왑 메모리를 사용할 수 있습니다. 결국 스왑 공간이 충분하지 않으면 시스템의 초과 구독으로 인해 Pod의 프로세스가 종료될 수 있습니다.
스왑을 비활성화하지 못하면 노드에서 MemoryPressure가 발생하고 있음을 인식하지 못하여 Pod가 스케줄링 요청에서 만든 메모리를 받지 못하게 됩니다. 결과적으로 메모리 Pod를 추가로 늘리기 위해 추가 Pod가 노드에 배치되어 궁극적으로 시스템 메모리 부족 (OOM) 이벤트가 발생할 위험이 높아집니다.
스왑이 활성화되면 사용 가능한 메모리에 대한 리소스 부족 처리 제거 임계 값이 예상대로 작동하지 않을 수 있습니다. 리소스 부족 처리를 활용하여 메모리 부족 상태에서 Pod를 노드에서 제거하고 메모리 부족 상태가 아닌 다른 노드에서 일정을 재조정할 수 있도록 합니다.
5.11.4. 노드 과다 할당 이해
오버 커밋된 환경에서는 최상의 시스템 동작을 제공하도록 노드를 올바르게 구성하는 것이 중요합니다.
노드가 시작되면 메모리 관리를 위한 커널 조정 가능한 플래그가 올바르게 설정됩니다. 커널은 실제 메모리가 소진되지 않는 한 메모리 할당에 실패해서는 안됩니다.
이 동작을 확인하기 위해 OpenShift Container Platform은 vm.overcommit_memory 매개변수를 1로 설정하여 기본 운영 체제 설정을 재정의하여 커널이 항상 메모리를 오버 커밋하도록 구성합니다.
OpenShift Container Platform은 vm.panic_on_oom 매개변수를 0으로 설정하여 메모리 부족시 커널이 패닉 상태가되지 않도록 구성합니다. 0으로 설정하면 커널이 OOM(메모리 부족) 상태에서 oom_killer를 호출하여 우선 순위에 따라 프로세스를 종료합니다.
노드에서 다음 명령을 실행하여 현재 설정을 볼 수 있습니다.
$ sysctl -a |grep commit
출력 예
#... vm.overcommit_memory = 0 #...
$ sysctl -a |grep panic
출력 예
#... vm.panic_on_oom = 0 #...
위의 플래그는 이미 노드에 설정되어 있어야하며 추가 조치가 필요하지 않습니다.
각 노드에 대해 다음 구성을 수행할 수도 있습니다.
- CPU CFS 할당량을 사용하여 CPU 제한 비활성화 또는 실행
- 시스템 프로세스의 리소스 예약
- Quality of Service (QoS) 계층에서의 메모리 예약
5.11.5. CPU CFS 할당량을 사용하여 CPU 제한 비활성화 또는 실행
기본적으로 노드는 Linux 커널에서 CFS (Completely Fair Scheduler) 할당량 지원을 사용하여 지정된 CPU 제한을 실행합니다.
CPU 제한 적용을 비활성화한 경우 노드에 미치는 영향을 이해해야 합니다.
- 컨테이너에 CPU 요청이 있는 경우 요청은 Linux 커널의 CFS 공유를 통해 계속 강제 적용됩니다.
- 컨테이너에 CPU 요청은 없지만 CPU 제한이 있는 경우 CPU 요청 기본값이 지정된 CPU 제한으로 설정되며 Linux 커널의 CFS 공유를 통해 강제 적용됩니다.
- 컨테이너에 CPU 요청 및 제한이 모두 있는 경우 Linux 커널의 CFS 공유를 통해 CPU 요청이 강제 적용되며 CPU 제한은 노드에 영향을 미치지 않습니다.
사전 요구 사항
다음 명령을 입력하여 구성할 노드 유형의 정적
MachineConfigPoolCRD와 연결된 라벨을 가져옵니다.$ oc edit machineconfigpool <name>
예를 들면 다음과 같습니다.
$ oc edit machineconfigpool worker
출력 예
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: creationTimestamp: "2022-11-16T15:34:25Z" generation: 4 labels: pools.operator.machineconfiguration.openshift.io/worker: "" 1 name: worker- 1
- 레이블은 Labels 아래에 표시됩니다.
작은 정보라벨이 없으면 다음과 같은 키/값 쌍을 추가합니다.
$ oc label machineconfigpool worker custom-kubelet=small-pods
프로세스
구성 변경을 위한 사용자 정의 리소스 (CR)를 만듭니다.
CPU 제한 비활성화를 위한 설정 예
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: disable-cpu-units 1 spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: "" 2 kubeletConfig: cpuCfsQuota: false 3
다음 명령을 실행하여 CR을 생성합니다.
$ oc create -f <file_name>.yaml
5.11.6. 시스템 프로세스의 리소스 예약
보다 안정적인 스케줄링을 제공하고 노드 리소스 오버 커밋을 최소화하기 위해 각 노드는 클러스터가 작동할 수 있도록 노드에서 실행하는 데 필요한 시스템 데몬에서 사용할 리소스의 일부를 예약할 수 있습니다. 특히 메모리와 같은 압축 불가능한 리소스의 경우 리소스를 예약하는 것이 좋습니다.
프로세스
pod가 아닌 프로세스의 리소스를 명시적으로 예약하려면 스케줄링에서 사용 가능한 리소스를 지정하여 노드 리소스를 할당합니다. 자세한 내용은 노드의 리소스 할당을 참조하십시오.
5.11.7. 노드의 오버 커밋 비활성화
이를 활성화하면 각 노드에서 오버 커밋을 비활성화할 수 있습니다.
프로세스
노드에서 오버 커밋을 비활성화하려면 해당 노드에서 다음 명령을 실행합니다.
$ sysctl -w vm.overcommit_memory=0
