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

더 안정적인 예약 기능을 제공하고 노드 리소스 과다 할당을 최소화하려면 기본 노드 구성 요소(예: kubelet, kube-proxy) 및 나머지 시스템 구성 요소(예: sshd, NetworkManager)에서 사용할 CPU 및 메모리 리소스의 일부를 예약하십시오. 예약할 리소스를 지정하면 Pod에서 사용할 수 있는 노드의 나머지 CPU 및 메모리 리소스에 대한 세부 정보가 스케줄러에 제공됩니다.

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

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

설정설명

kube-reserved

이 설정은 OpenShift Container Platform과 함께 사용되지 않습니다. system-reserved 설정에 예약할 CPU 및 메모리 리소스를 추가합니다.

system-reserved

이 설정은 노드 구성 요소 및 시스템 구성 요소를 위해 예약할 리소스를 확인합니다. 기본 설정은 OpenShift Container Platform 및 Machine Config Operator 버전에 따라 다릅니다. machine-config-operator 리포지토리에서 기본 systemReserved 매개변수를 확인합니다.

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

참고

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

5.8.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에 제공됩니다.

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

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

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

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

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

5.8.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 종료됩니다.

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

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

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