6.9. OpenShift Container Platform 클러스터의 노드에 리소스 할당

더 안정적인 예약 기능을 제공하고 노드 리소스 과다 할당을 최소화하려면 기본 노드 구성 요소(예: kubelet, kube-proxy) 및 나머지 시스템 구성 요소(예: sshd, NetworkManager)에서 사용할 CPU 및 메모리 리소스의 일부를 예약하십시오. 예약할 리소스를 지정하면 Pod에서 사용할 수 있는 노드의 나머지 CPU 및 메모리 리소스에 대한 세부 정보가 스케줄러에 제공됩니다. OpenShift Container Platform에서 노드에 대해 최적의 system-reserved CPU 및 메모리 리소스를 자동으로 결정하도록 허용하거나 수동으로 노드에 가장 적합한 리소스를 결정하고 설정할 수 있습니다.

중요

리소스 값을 수동으로 설정하려면 kubelet 구성 CR을 사용해야 합니다. 머신 구성 CR을 사용할 수 없습니다.

6.9.1. 노드에 리소스를 할당하는 방법 이해

OpenShift Container Platform에서 노드 구성 요소용으로 예약된 CPU 및 메모리 리소스는 다음 두 노드 설정을 기반으로 합니다.

설정	설명
`kube-reserved`	이 설정은 OpenShift Container Platform과 함께 사용되지 않습니다. `system-reserved` 설정에 예약할 CPU 및 메모리 리소스를 추가합니다.
`system-reserved`	이 설정은 노드 구성 요소 및 시스템 구성 요소(예: CRI-O 및 Kubelet)에 예약할 리소스를 식별합니다. 기본 설정은 OpenShift Container Platform 및 Machine Config Operator 버전에 따라 다릅니다. `machine-config-operator` 리포지토리에서 기본 `systemReserved` 매개변수를 확인합니다.

플래그를 설정하지 않으면 기본값이 사용됩니다. 플래그를 설정하지 않은 경우 할당된 리소스는 할당 가능 리소스를 도입하기 전과 마찬가지로 노드의 용량으로 설정됩니다.

참고

reservedSystemCPUs 매개변수를 사용하여 특별히 예약한 CPU는 kube-reserved 또는 system-reserved를 사용하여 할당할 수 없습니다.

6.9.1.1. OpenShift Container Platform에서 할당된 리소스를 계산하는 방법

할당된 리소스 양은 다음 공식에 따라 계산됩니다.

[Allocatable] = [Node Capacity] - [system-reserved] - [Hard-Eviction-Thresholds]

참고

Allocatable에서 Hard-Eviction-Thresholds를 보류하면 Allocatable 값이 노드 수준에서 Pod에 적용되므로 시스템 신뢰도가 향상됩니다.

Allocatable이 음수인 경우 0으로 설정됩니다.

각 노드는 컨테이너 런타임 및 kubelet에서 사용하는 시스템 리소스를 보고합니다. system-reserved 매개변수 구성을 단순화하려면 Node Summary API를 사용하여 노드의 리소스 사용량을 확인합니다. 노드 요약은 /api/v1/nodes/<node>/proxy/stats/summary에 제공됩니다.

6.9.1.2. 노드에서 리소스 제약 조건을 적용하는 방법

노드는 구성된 할당 가능 값을 기반으로 Pod에서 사용할 수 있는 총 리소스 양을 제한할 수 있습니다. 이 기능을 사용하면 컨테이너 런타임 및 노드 에이전트와 같은 시스템 서비스에 필요한 CPU 및 메모리 리소스를 Pod에서 사용하지 못하도록 하여 노드의 안정성이 크게 향상됩니다. 관리자는 노드 안정성을 개선하기 위해 리소스 사용량 목표에 따라 리소스를 예약해야 합니다.

노드는 서비스 품질을 적용하는 새 cgroup 계층을 사용하여 리소스 제약 조건을 적용합니다. 모든 Pod는 시스템 데몬과는 별도의 전용 cgroup 계층에서 시작됩니다.

관리자는 서비스 품질이 보장된 Pod와 비슷한 시스템 데몬을 처리해야 합니다. 시스템 데몬은 바인딩 제어 그룹 내에서 버스트될 수 있으며 이 동작은 클러스터 배포의 일부로 관리해야 합니다. system-reserved에 CPU 및 메모리 리소스를 지정하여 시스템 데몬을 위한 CPU 및 메모리 리소스를 예약합니다.

system-reserved 제한을 강제 적용하여 중요한 시스템 서비스에서 CPU 및 메모리 리소스를 수신하지 못하도록 할 수 있습니다. 그 결과 메모리 부족 종료자에서 중요한 시스템 서비스를 종료할 수 있습니다. 정확한 추정치를 결정하기 위해 노드를 철저히 프로파일링하고 메모리 부족 종료자에서 해당 그룹의 프로세스를 종료할 때 중요한 시스템 서비스를 복구할 수 있다고 확신하는 경우에만 system-reserved를 강제 적용하는 것이 좋습니다.

6.9.1.3. 제거 임계값 이해

노드가 메모리 부족 상태에 있는 경우 전체 노드와 해당 노드에서 실행 중인 모든 Pod에 영향을 미칠 수 있습니다. 예를 들어 시스템 데몬에서 예약된 메모리보다 많은 양을 사용하면 메모리 부족 이벤트가 트리거될 수 있습니다. 노드에서는 시스템 메모리 부족 이벤트를 방지하거나 줄이기 위해 리소스 부족 처리 기능을 제공합니다.

--eviction-hard 플래그를 사용하여 일부 메모리를 예약할 수 있습니다. 노드는 노드의 메모리 가용성이 이 절대값 또는 백분율 아래로 떨어지면 Pod를 제거하려고 합니다. 노드에 시스템 데몬이 없는 경우 Pod는 메모리 capacity - eviction-hard로 제한됩니다. 이로 인해 메모리 부족 상태에 도달하기 전에 제거할 버퍼로 따로 설정된 리소스를 Pod에 사용할 수 없습니다.

다음은 메모리에 할당 가능한 노드의 영향을 보여주는 예입니다.

노드 용량이 32Gi입니다.
--system-reserved가 3Gi입니다.
--eviction-hard가 100Mi로 설정되어 있습니다.

이 노드의 경우 유효 노드 할당 가능 값은 28.9Gi입니다. 노드 및 시스템 구성 요소에서 예약된 용량을 모두 사용하는 경우 Pod에 사용 가능한 메모리는 28.9Gi이고 이 임계값을 초과하는 경우 Kubelet은 Pod를 제거합니다.

노드 할당 가능 28.9Gi를 최상위 cgroups와 함께 적용하면 Pod에서 28.9Gi를 초과하지 않습니다. 시스템 데몬의 메모리 사용량이 3.1Gi를 초과하면 제거 작업이 수행됩니다.

위 예에서 시스템 데몬이 예약된 용량을 모두 사용하지 않는 경우 노드 제거가 시작되기 전에 Pod의 바인딩 cgroup에서 memcg OOM이 종료됩니다. 이러한 상황에서 QoS를 더 잘 적용하기 위해 노드는 모든 Pod가 Node Allocatable + Eviction Hard Thresholds가 되도록 최상위 cgroup에 하드 제거 임계값을 적용합니다.

시스템 데몬에서 예약된 용량을 모두 사용하지 않는 경우 노드는 Pod의 메모리 사용량이 28.9Gi를 초과할 때마다 Pod를 제거합니다. 제거 작업이 제시간에 수행되지 않아 Pod에서 29Gi의 메모리를 사용하면 Pod가 OOM 종료됩니다.

6.9.1.4. 스케줄러에서 리소스 가용성을 결정하는 방법

스케줄러는 node.Status.Capacity가 아닌 node.Status.Allocatable의 값을 사용하여 노드가 Pod 예약 후보가 될지 결정합니다.

기본적으로 노드는 클러스터에서 전체 머신 용량을 예약할 수 있는 것으로 보고합니다.

6.9.2. 프로세스 ID 제한 이해

PID(프로세스 ID)는 시스템에서 현재 실행 중인 각 프로세스 또는 스레드에 Linux 커널에서 할당한 고유 식별자입니다. 시스템에서 동시에 실행할 수 있는 프로세스 수는 Linux 커널의 4,194,304로 제한됩니다. 이 숫자는 메모리, CPU 및 디스크 공간과 같은 다른 시스템 리소스에 대한 제한된 액세스의 영향을 받을 수도 있습니다.

OpenShift Container Platform에서 클러스터에서 작업을 예약하기 전에 PID(프로세스 ID) 사용에 대해 지원되는 다음 두 가지 제한 사항을 고려하십시오.

Pod당 최대 PID 수입니다.
OpenShift Container Platform 4.11 이상에서는 기본값은 4,096입니다. 이 값은 노드에 설정된 podPidsLimit 매개변수에 의해 제어됩니다.
chroot 환경에서 다음 명령을 실행하여 노드의 현재 PID 제한을 볼 수 있습니다.
```
sh-5.1# cat /etc/kubernetes/kubelet.conf | grep -i pids
```
출력 예
```
"podPidsLimit": 4096,
```
KubeletConfig 오브젝트를 사용하여 podPidsLimit 을 변경할 수 있습니다. " kubelet 매개변수를 편집하기 위해 KubeletConfig CR 생성"을 참조하십시오.
컨테이너는 상위 Pod의 podPidsLimit 값을 상속하므로 커널은 두 제한 중 더 낮은 값을 적용합니다. 예를 들어 컨테이너 PID 제한이 최대값으로 설정되어 있지만 Pod PID 제한이 4096 인 경우 Pod에 있는 각 컨테이너의 PID 제한이 4096으로 제한됩니다.
노드당 최대 PID 수입니다.
기본값은 노드 리소스에 따라 다릅니다. OpenShift Container Platform에서 이 값은 kubelet 구성의 systemReserved 매개변수에 의해 제어되며, 노드의 총 리소스에 따라 각 노드에 PID를 예약합니다. 자세한 내용은 "OpenShift Container Platform 클러스터의 노드에 대한 리소스 할당"을 참조하십시오.

Pod가 Pod당 허용되는 최대 PID 수를 초과하면 Pod가 올바르게 작동을 중지하고 노드에서 제거될 수 있습니다. 자세한 내용은 제거 신호 및 임계값에 대한 Kubernetes 문서를 참조하십시오.

노드가 노드당 허용되는 최대 PID 수를 초과하면 새 프로세스에 PID를 할당할 수 없으므로 노드가 불안정해질 수 있습니다. 추가 프로세스를 생성하지 않고 기존 프로세스를 완료할 수 없는 경우 전체 노드를 사용할 수 없게 되고 재부팅이 필요할 수 있습니다. 이 경우 실행 중인 프로세스 및 애플리케이션에 따라 데이터가 손실될 수 있습니다. 고객 관리자 및 Red Hat 사이트 안정성 엔지니어링은 이 임계값에 도달하면 알림을 받으며 작업자 노드에 PIDPressure 경고가 표시됩니다.

추가 리소스

6.9.2.1. OpenShift Container Platform Pod에 대해 더 높은 프로세스 ID 제한을 설정하는 위험

Pod의 podPidsLimit 매개변수는 해당 Pod에서 동시에 실행할 수 있는 최대 프로세스 및 스레드 수를 제어합니다.

podPidsLimit 의 값을 기본값인 4,096에서 최대 16,384로 늘릴 수 있습니다. podPidsLimit 을 변경하려면 영향을 받는 노드를 재부팅해야 하므로 이 값을 변경하면 애플리케이션의 다운타임이 발생할 수 있습니다.

노드당 다수의 Pod를 실행 중이고 노드에 podPidsLimit 값이 높은 경우 노드의 PID 최대값이 초과될 위험이 있습니다.

노드의 PID 최대값을 초과하지 않고 단일 노드에서 동시에 실행할 수 있는 최대 Pod 수를 찾으려면 podPidsLimit 값으로 3,650,000을 나눕니다. 예를 들어 podPidsLimit 값이 16,384이고 Pod가 프로세스 ID 수에 가깝게 사용할 것으로 예상되는 경우 단일 노드에서 222 Pod를 안전하게 실행할 수 있습니다.

참고

memory, CPU 및 사용 가능한 스토리지는 podPidsLimit 값이 적절하게 설정된 경우에도 동시에 실행할 수 있는 최대 Pod 수를 제한할 수 있습니다.

6.9.3. 노드에 대한 리소스 자동 할당

OpenShift Container Platform은 특정 머신 구성 풀과 연결된 노드에 대해 최적의 system-reserved CPU 및 메모리 리소스를 자동으로 확인하고 노드가 시작될 때 해당 값으로 노드를 업데이트할 수 있습니다. 기본적으로 system-reserved CPU는 500m 이고 system-reserved 메모리는 1Gi 입니다.

노드에서 system-reserved 리소스를 자동으로 결정하고 할당하려면 KubeletConfig CR(사용자 정의 리소스)을 생성하여 autoSizingReserved: true 매개변수를 설정합니다. 각 노드의 스크립트는 각 노드에 설치된 CPU 및 메모리 용량을 기반으로 예약된 각 리소스에 대한 최적 값을 계산합니다. 이 스크립트는 용량을 늘리려면 예약된 리소스가 그에 따라 증가해야 한다는 점을 고려합니다.

최적의 시스템 보존 설정을 자동으로 결정하면 클러스터가 효율적으로 실행되고 있고 값을 수동으로 계산하고 업데이트할 필요 없이 CRI-O 및 kubelet과 같은 시스템 구성 요소의 리소스 부족으로 인한 노드 실패를 방지할 수 있습니다.

이 기능은 기본적으로 비활성화되어 있습니다.

사전 요구 사항

다음 명령을 입력하여 구성할 노드 유형의 정적 MachineConfigPool 오브젝트와 연결된 라벨을 가져옵니다.

$ 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: 레이블은 라벨 아래에 표시됩니다.

작은 정보

적절한 라벨이 없는 경우 다음과 같은 키/값 쌍을 추가합니다.

$ oc label machineconfigpool worker custom-kubelet=small-pods

프로세스

구성 변경에 대한 CR(사용자 정의 리소스)을 생성합니다.
리소스 할당 CR 구성 샘플
```
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: dynamic-node 1
spec:
  autoSizingReserved: true 2
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 3
#...
```
1
CR에 이름을 지정합니다.
2
OpenShift Container Platform이 지정된 라벨과 연결된 노드에 system-reserved 리소스를 자동으로 결정하도록 하려면 autoSizingReserved 매개변수를 true 로 설정합니다. 해당 노드에서 자동 할당을 비활성화하려면 이 매개변수를 false 로 설정합니다.
3
"사전 요구 사항" 섹션에 구성한 머신 구성 풀에서 라벨을 지정합니다. custom-kubelet: small-pods 또는 기본 레이블, pool .operator.machineconfiguration.openshift.io/worker: ""와 같은 머신 구성 풀에 대해 원하는 레이블을 선택할 수 있습니다.
이전 예제에서는 모든 작업자 노드에서 자동 리소스 할당을 활성화합니다. OpenShift Container Platform은 노드를 비우고 kubelet 구성을 적용한 다음 노드를 다시 시작합니다.
다음 명령을 입력하여 CR을 생성합니다.
```
$ oc create -f <file_name>.yaml
```

검증

다음 명령을 입력하여 구성한 노드에 로그인합니다.
```
$ oc debug node/<node_name>
```
디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다.
```
# chroot /host
```
/etc/node-sizing.env 파일을 확인합니다.
출력 예
```
SYSTEM_RESERVED_MEMORY=3Gi
SYSTEM_RESERVED_CPU=0.08
```
kubelet은 /etc/node-sizing.env 파일에서 system-reserved 값을 사용합니다. 이전 예에서 작업자 노드에는 0.08 CPU 및 3Gi의 메모리가 할당됩니다. 최적 값이 표시되는 데 몇 분이 걸릴 수 있습니다.

6.9.4. 노드에 수동으로 리소스 할당

OpenShift Container Platform은 할당을 위해 CPU 및 메모리 리소스 유형을 지원합니다. ephemeral-resource 리소스 유형도 지원됩니다. cpu 유형의 경우 200m,0.5 또는 1 과 같은 코어 단위로 리소스 수량을 지정합니다. memory 및 ephemeral-storage 의 경우 200Ki,50Mi 또는 5Gi 와 같은 바이트 단위로 리소스 수량을 지정합니다. 기본적으로 system-reserved CPU는 500m 이고 system-reserved 메모리는 1Gi 입니다.

관리자는 일련의 <resource _type>=<resource_quantity> 쌍(예: cpu=200m,memory=512Mi )을 통해 kubelet 구성 CR(사용자 정의 리소스)을 사용하여 이러한 값을 설정할 수 있습니다.

중요

kubelet 구성 CR을 사용하여 리소스 값을 수동으로 설정해야 합니다. 머신 구성 CR을 사용할 수 없습니다.

권장 system-reserved 값에 대한 자세한 내용은 권장 system-reserved 값을 참조하십시오.

사전 요구 사항

다음 명령을 입력하여 구성할 노드 유형의 정적 MachineConfigPool CRD와 연결된 라벨을 가져옵니다.

$ 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)를 만듭니다.

리소스 할당 CR 구성 샘플

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-allocatable 1
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: "" 2
  kubeletConfig:
    systemReserved: 3
      cpu: 1000m
      memory: 1Gi
#...

1: CR에 이름을 지정합니다.
2: 머신 구성 풀에서 라벨을 지정합니다.
3: 노드 구성 요소 및 시스템 구성 요소를 위해 예약할 리소스를 지정합니다.

다음 명령을 실행하여 CR을 생성합니다.
```
$ oc create -f <file_name>.yaml
```

6.9. OpenShift Container Platform 클러스터의 노드에 리소스 할당

6.9.1. 노드에 리소스를 할당하는 방법 이해

6.9.1.1. OpenShift Container Platform에서 할당된 리소스를 계산하는 방법

6.9.1.2. 노드에서 리소스 제약 조건을 적용하는 방법

6.9.1.3. 제거 임계값 이해

6.9.1.4. 스케줄러에서 리소스 가용성을 결정하는 방법

6.9.2. 프로세스 ID 제한 이해

6.9.2.1. OpenShift Container Platform Pod에 대해 더 높은 프로세스 ID 제한을 설정하는 위험

6.9.3. 노드에 대한 리소스 자동 할당

6.9.4. 노드에 수동으로 리소스 할당

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links