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 및 메모리 리소스는 다음 두 노드 설정을 기반으로 합니다.
설정 | 설명 |
---|---|
|
이 설정은 OpenShift Container Platform과 함께 사용되지 않습니다. |
|
이 설정은 CRI-O 및 Kubelet과 같은 노드 구성 요소 및 시스템 구성 요소를 예약할 리소스를 식별합니다. 기본 설정은 OpenShift Container Platform 및 Machine Config Operator 버전에 따라 다릅니다. |
플래그를 설정하지 않으면 기본값이 사용됩니다. 플래그를 설정하지 않은 경우 할당된 리소스는 할당 가능 리소스를 도입하기 전과 마찬가지로 노드의 용량으로 설정됩니다.
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. 노드의 리소스 자동 할당
OpenShift Container Platform은 특정 머신 구성 풀과 연결된 노드의 system-reserved
CPU 및 메모리 리소스를 자동으로 확인하고 노드가 시작될 때 해당 값으로 노드를 업데이트할 수 있습니다. 기본적으로 system-reserved
CPU는 500m
이고 system-reserved
메모리는 1Gi
입니다.
노드에서 system-reserved
리소스를 자동으로 확인하고 할당하려면 KubeletConfig
CR(사용자 정의 리소스)을 생성하여 autoSizingReserved: true
매개변수를 설정합니다. 각 노드의 스크립트는 각 노드에 설치된 CPU 및 메모리 용량에 따라 예약된 각 리소스의 최적 값을 계산합니다. 이 스크립트는 용량을 늘리려면 예약된 리소스가 그에 따라 증가해야 한다는 점을 고려합니다.
최적의 system-reserved
설정을 자동으로 확인하면 값을 수동으로 계산 및 업데이트할 필요 없이 클러스터가 효율적으로 실행되고 시스템 구성 요소(예: 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
- 레이블은
Labels
아래에 표시됩니다.
작은 정보적절한 라벨이 없으면 다음과 같은 키/값 쌍을 추가합니다.
$ 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
, default 레이블, 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.3. 노드에 수동으로 리소스 할당
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> 쌍 집합(예:
)을 통해 kubelet 구성 CR(사용자 정의 리소스)을 사용하여 이러한 값을 설정할 수 있습니다.
cpu=200m,memory=
512Mi
리소스 값을 수동으로 설정하려면 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 #...
다음 명령을 실행하여 CR을 생성합니다.
$ oc create -f <file_name>.yaml