6.11. OpenShift Container Platform 클러스터의 노드에 리소스 할당
더 안정적인 예약 기능을 제공하고 노드 리소스 과다 할당을 최소화하려면 기본 노드 구성 요소(예: kubelet
, kube-proxy
) 및 나머지 시스템 구성 요소(예: sshd
, NetworkManager
)에서 사용할 CPU 및 메모리 리소스의 일부를 예약하십시오. 예약할 리소스를 지정하면 Pod에서 사용할 수 있는 노드의 나머지 CPU 및 메모리 리소스에 대한 세부 정보가 스케줄러에 제공됩니다. OpenShift Container Platform이 노드에 대한 최적의 시스템 예약
CPU 및 메모리 리소스를 자동으로 결정하도록 허용할 수도 있고, 노드에 가장 적합한 리소스를 수동으로 결정하고 설정할 수도 있습니다.
리소스 값을 수동으로 설정하려면 kubelet config CR을 사용해야 합니다. 머신 구성 CR을 사용할 수 없습니다.
6.11.1. 노드에 리소스를 할당하는 방법 이해 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서 노드 구성 요소용으로 예약된 CPU 및 메모리 리소스는 다음 두 노드 설정을 기반으로 합니다.
설정 | 설명 |
---|---|
|
이 설정은 OpenShift Container Platform과 함께 사용되지 않습니다. |
|
이 설정은 CRI-O 및 Kubelet과 같은 노드 구성 요소와 시스템 구성 요소에 대해 예약할 리소스를 식별합니다. 기본 설정은 OpenShift Container Platform 및 Machine Config Operator 버전에 따라 다릅니다. |
플래그를 설정하지 않으면 기본값이 사용됩니다. 플래그를 설정하지 않은 경우 할당된 리소스는 할당 가능 리소스를 도입하기 전과 마찬가지로 노드의 용량으로 설정됩니다.
reservedSystemCPUs
매개변수를 사용하여 특별히 예약한 CPU는 kube-reserved
또는 system-reserved
를 사용하여 할당할 수 없습니다.
6.11.1.1. OpenShift Container Platform에서 할당된 리소스를 계산하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
할당된 리소스 양은 다음 공식에 따라 계산됩니다.
[Allocatable] = [Node Capacity] - [system-reserved] - [Hard-Eviction-Thresholds]
[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.11.1.2. 노드에서 리소스 제약 조건을 적용하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
노드는 구성된 할당 가능 값을 기반으로 Pod에서 사용할 수 있는 총 리소스 양을 제한할 수 있습니다. 이 기능을 사용하면 컨테이너 런타임 및 노드 에이전트와 같은 시스템 서비스에 필요한 CPU 및 메모리 리소스를 Pod에서 사용하지 못하도록 하여 노드의 안정성이 크게 향상됩니다. 관리자는 노드 안정성을 개선하기 위해 리소스 사용량 목표에 따라 리소스를 예약해야 합니다.
노드는 서비스 품질을 적용하는 새 cgroup 계층을 사용하여 리소스 제약 조건을 적용합니다. 모든 Pod는 시스템 데몬과는 별도의 전용 cgroup 계층에서 시작됩니다.
관리자는 서비스 품질이 보장된 Pod와 비슷한 시스템 데몬을 처리해야 합니다. 시스템 데몬은 바인딩 제어 그룹 내에서 버스트될 수 있으며 이 동작은 클러스터 배포의 일부로 관리해야 합니다. system-reserved
에 CPU 및 메모리 리소스를 지정하여 시스템 데몬을 위한 CPU 및 메모리 리소스를 예약합니다.
system-reserved
제한을 강제 적용하여 중요한 시스템 서비스에서 CPU 및 메모리 리소스를 수신하지 못하도록 할 수 있습니다. 그 결과 메모리 부족 종료자에서 중요한 시스템 서비스를 종료할 수 있습니다. 정확한 추정치를 결정하기 위해 노드를 철저히 프로파일링하고 메모리 부족 종료자에서 해당 그룹의 프로세스를 종료할 때 중요한 시스템 서비스를 복구할 수 있다고 확신하는 경우에만 system-reserved
를 강제 적용하는 것이 좋습니다.
6.11.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.11.1.4. 스케줄러에서 리소스 가용성을 결정하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
스케줄러는 node.Status.Capacity
가 아닌 node.Status.Allocatable
의 값을 사용하여 노드가 Pod 예약 후보가 될지 결정합니다.
기본적으로 노드는 클러스터에서 전체 머신 용량을 예약할 수 있는 것으로 보고합니다.
6.11.2. 프로세스 ID 제한 이해 링크 복사링크가 클립보드에 복사되었습니다!
프로세스 식별자(PID)는 Linux 커널이 시스템에서 현재 실행 중인 각 프로세스나 스레드에 할당하는 고유 식별자입니다. Linux 커널은 시스템에서 동시에 실행할 수 있는 프로세스 수를 4,194,304개로 제한합니다. 이 숫자는 메모리, CPU, 디스크 공간 등 다른 시스템 리소스에 대한 액세스가 제한되어서도 영향을 받을 수 있습니다.
OpenShift Container Platform에서 클러스터에서 작업을 예약하기 전에 프로세스 ID(PID) 사용에 대해 지원되는 다음 두 가지 제한을 고려하세요.
포드당 PID의 최대 수.
OpenShift Container Platform 4.11 이상에서는 기본값이 4,096입니다. 이 값은 노드에 설정된
podPidsLimit
매개변수에 의해 제어됩니다.chroot
환경에서 다음 명령을 실행하면 노드의 현재 PID 제한을 볼 수 있습니다.cat /etc/kubernetes/kubelet.conf | grep -i pids
sh-5.1# cat /etc/kubernetes/kubelet.conf | grep -i pids
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
"podPidsLimit": 4096,
"podPidsLimit": 4096,
Copy to Clipboard Copied! Toggle word wrap Toggle overflow KubeletConfig
객체를 사용하여podPidsLimit을
변경할 수 있습니다. "kubelet 매개변수를 편집하기 위한 KubeletConfig CR 만들기"를 참조하세요.컨테이너는 부모 Pod로부터
podPidsLimit
값을 상속하므로 커널은 두 제한 중 더 낮은 제한을 적용합니다. 예를 들어, 컨테이너 PID 제한이 최대값으로 설정되어 있지만 Pod PID 제한이4096
인 경우 Pod에 있는 각 컨테이너의 PID 제한은 4096으로 제한됩니다.노드당 PID의 최대 수.
기본값은 노드 리소스에 따라 달라집니다. OpenShift Container Platform에서 이 값은 kubelet 구성의
systemReserved
매개변수에 의해 제어되며, 이 매개변수는 노드의 총 리소스에 따라 각 노드의 PID를 예약합니다. 자세한 내용은 "OpenShift Container Platform 클러스터의 노드에 리소스 할당"을 참조하세요.
포드가 포드당 허용되는 최대 PID 수를 초과하면 포드가 제대로 작동하지 않고 노드에서 추방될 수 있습니다. 자세한 내용은 Kubernetes 문서에서 퇴거 신호 및 임계값을 참조하세요.
노드가 노드당 허용되는 최대 PID 수를 초과하면 새로운 프로세스에 PID를 할당할 수 없기 때문에 노드가 불안정해질 수 있습니다. 기존 프로세스가 추가 프로세스를 생성하지 않고는 완료될 수 없는 경우 전체 노드를 사용할 수 없게 되어 재부팅이 필요할 수 있습니다. 이러한 상황은 실행되는 프로세스와 애플리케이션에 따라 데이터 손실로 이어질 수 있습니다. 이 임계값에 도달하면 고객 관리자와 Red Hat Site Reliability Engineering에 알림이 전달되고, Worker 노드에서 PIDPressure
경고가 클러스터 로그에 표시됩니다.
6.11.2.1. OpenShift Container Platform Pod에 대해 더 높은 프로세스 ID 제한을 설정하는 위험 링크 복사링크가 클립보드에 복사되었습니다!
Pod의 podPidsLimit
매개변수는 해당 Pod에서 동시에 실행할 수 있는 프로세스와 스레드의 최대 수를 제어합니다.
podPidsLimit
값을 기본값인 4,096에서 최대 16,384까지 늘릴 수 있습니다. 이 값을 변경하면 podPidsLimit을
변경하면 영향을 받는 노드를 재부팅해야 하므로 애플리케이션 가동 중지 시간이 발생할 수 있습니다.
노드당 많은 수의 Pod를 실행하고 노드의 podPidsLimit
값이 높으면 노드의 PID 최대값을 초과할 위험이 있습니다.
노드의 PID 최대값을 초과하지 않고 단일 노드에서 동시에 실행할 수 있는 최대 Pod 수를 찾으려면 3,650,000을 podPidsLimit
값으로 나누세요. 예를 들어, podPidsLimit
값이 16,384이고 포드가 해당 수에 가까운 프로세스 ID를 사용할 것으로 예상하는 경우 단일 노드에서 222개의 포드를 안전하게 실행할 수 있습니다.
podPidsLimit
값이 적절하게 설정된 경우에도 메모리, CPU 및 사용 가능한 저장 공간은 동시에 실행할 수 있는 최대 포드 수를 제한할 수 있습니다.
6.11.3. 노드에 대한 리소스 자동 할당 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 특정 머신 구성 풀과 연관된 노드에 대해 최적의 시스템 예약
CPU 및 메모리 리소스를 자동으로 결정하고 노드가 시작될 때 해당 값으로 노드를 업데이트할 수 있습니다. 기본적으로 시스템 예약
CPU는 500m
이고 시스템 예약
메모리는 1Gi
입니다.
노드에서 시스템 예약
리소스를 자동으로 결정하고 할당하려면 KubeletConfig
사용자 지정 리소스(CR)를 만들어 autoSizingReserved: true
매개변수를 설정합니다. 각 노드의 스크립트는 각 노드에 설치된 CPU와 메모리 용량을 기반으로 해당 예약 리소스에 대한 최적 값을 계산합니다. 스크립트는 용량이 증가하면 예약된 리소스도 그에 맞게 증가해야 한다는 점을 고려합니다.
최적의 시스템 예약
설정을 자동으로 결정하면 클러스터가 효율적으로 실행되고 CRI-O 및 kubelet과 같은 시스템 구성 요소의 리소스 부족으로 인한 노드 장애가 방지되며, 값을 수동으로 계산하고 업데이트할 필요가 없습니다.
이 기능은 기본적으로 비활성화되어 있습니다.
사전 요구 사항
다음 명령을 입력하여 구성하려는 노드 유형에 대한 정적
MachineConfigPool
개체와 연관된 레이블을 가져옵니다.oc edit machineconfigpool <name>
$ oc edit machineconfigpool <name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들면 다음과 같습니다.
oc edit machineconfigpool worker
$ oc edit machineconfigpool worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 레이블은
레이블
아래에 나타납니다.
작은 정보적절한 레이블이 없으면 다음과 같은 키/값 쌍을 추가합니다.
oc label machineconfigpool worker custom-kubelet=small-pods
$ oc label machineconfigpool worker custom-kubelet=small-pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
프로세스
구성 변경에 대한 사용자 지정 리소스(CR)를 만듭니다.
리소스 할당 CR 구성 샘플
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- CR에 이름을 지정합니다.
- 2
- 지정된 레이블과 연관된 노드에서
시스템 예약
리소스를 자동으로 결정하고 할당할 수 있도록autoSizingReserved
매개변수를true
로 설정합니다. 해당 노드에서 자동 할당을 비활성화하려면 이 매개변수를false
로 설정합니다. - 3
- "필수 구성 요소" 섹션에서 구성한 머신 구성 풀의 레이블을 지정합니다.
custom-kubelet: small-pods
또는 기본 레이블pools.operator.machineconfiguration.openshift.io/worker: ""
와 같이 머신 구성 풀에 대해 원하는 레이블을 선택할 수 있습니다.
이전 예제에서는 모든 작업자 노드에서 자동으로 리소스를 할당할 수 있습니다. OpenShift Container Platform은 노드를 비우고, kubelet 구성을 적용하고, 노드를 다시 시작합니다.
다음 명령을 입력하여 CR을 만듭니다.
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 입력하여 구성한 노드에 로그인합니다.
oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다.chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/node-sizing.env
파일을 확인하세요.출력 예
SYSTEM_RESERVED_MEMORY=3Gi SYSTEM_RESERVED_CPU=0.08
SYSTEM_RESERVED_MEMORY=3Gi SYSTEM_RESERVED_CPU=0.08
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubelet은
/etc/node-sizing.env
파일에 있는시스템 예약
값을 사용합니다. 이전 예에서 작업자 노드에는0.08
CPU와 3Gi 메모리가 할당되었습니다. 최적의 값이 나타나기까지 몇 분이 걸릴 수 있습니다.
6.11.4. 노드에 대한 리소스를 수동으로 할당 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 할당을 위해 CPU 및 메모리 리소스 유형을 지원합니다. ephemeral-resource
리소스 유형도 지원됩니다. CPU
유형의 경우 200m
, 0.5
또는 1
과 같이 코어 단위로 리소스 수량을 지정합니다. 메모리
와 임시 저장소
의 경우 200Ki
, 50Mi
또는 5Gi
와 같이 바이트 단위로 리소스 수량을 지정합니다. 기본적으로 시스템 예약
CPU는 500m
이고 시스템 예약
메모리는 1Gi
입니다.
관리자는 <resource_type>=<resource_quantity>
쌍(예: cpu=200m, memory=512Mi
)을 통해 kubelet 구성 사용자 정의 리소스(CR)를 사용하여 이러한 값을 설정할 수 있습니다.
리소스 값을 수동으로 설정하려면 kubelet config CR을 사용해야 합니다. 머신 구성 CR을 사용할 수 없습니다.
권장되는 시스템 예약
값에 대한 자세한 내용은 권장되는 시스템 예약 값을 참조하세요.
사전 요구 사항
다음 명령을 입력하여 구성하려는 노드 유형에 대한 정적
MachineConfigPool
CRD와 연관된 레이블을 가져옵니다.oc edit machineconfigpool <name>
$ oc edit machineconfigpool <name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들면 다음과 같습니다.
oc edit machineconfigpool worker
$ oc edit machineconfigpool worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 레이블은 레이블 아래에 나타납니다.
작은 정보레이블이 없으면 다음과 같은 키/값 쌍을 추가합니다.
oc label machineconfigpool worker custom-kubelet=small-pods
$ oc label machineconfigpool worker custom-kubelet=small-pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
프로세스
구성 변경을 위한 사용자 정의 리소스 (CR)를 만듭니다.
리소스 할당 CR 구성 샘플
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 CR을 만듭니다.
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow