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

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

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

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

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

기본적으로 OpenShift Container Platform은 시스템 프로세스에 대해 예약해야 하는 CPU 양을 계산하고 cgroup 제어를 사용하여 CPU가 구성된 가중치 및 제한에 따라 배포되도록 합니다.

이 적용은 노드 내의 CPU 경합 시 적용됩니다. 노드가 CPU 부족 상태에 있지 않은 경우 시스템 프로세스에서 사용되지 않는 CPU를 사용할 수 있는 경우 예약된 공유보다 많은 것을 사용할 수 있습니다.

OpenShift Container Platform은 systemReservedCgroup 을 사용하고 kubelet 구성에서 NodeAllocatable 매개변수를 적용하여 이 CPU 적용을 수행합니다.

기본적으로 systemReservedCgroup 매개변수는 /system.slice 로 설정되어 있으며, 이 매개변수는 kubelet, CRI-O 및 기타 시스템 서비스를 포함하는 systemd system.slice cgroup에 CPU 제한을 적용합니다. enforceNodeAllocatable 매개변수는 pod 및 system-reserved-compressible 으로 설정되어 Pod와 system-reserved 리소스 모두에 노드 할당 가능 제한을 적용합니다.

이 적용의 예로, 0.5 CPU가 4코어 노드의 시스템 데몬용으로 예약된 경우 systemd system.slice cgroup은 경합 중에 많은 CPU가 나머지 3.5 CPU의 예상 공유를 수신하게 됩니다. 시스템 데몬이 CPU 제한에 도달하면 OpenShift Container Platform 제한은 제한되지만 데몬은 종료되지 않습니다. OpenShift Container Platform은 system.slice cgroup의 프로세스에 할당된 CPU 시간을 줄여 더 오랜 기간 동안 작업을 분산시킵니다.

그러나 kubelet은 성능 프로필에서 사용하는 systemReservedCgroup 설정과 reservedSystemCPUs 설정을 동시에 적용할 수 없습니다. reservedSystemCPUs 로 구성된 성능 프로필을 적용하는 경우 OpenShift Container Platform은 다음 작업을 수행합니다.

KubeletConfig 오브젝트를 사용하여 특정 머신 구성 풀의 노드에 대한 기본 적용 동작을 비활성화할 수 있습니다. 다음과 같은 이유로 기능을 비활성화할 수 있습니다.

다음 kubelet 구성은 CPU 예약 적용을 비활성화합니다.

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: 80-custom-system-reserved
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  kubeletConfig:
    apiVersion: kubelet.config.k8s.io/v1beta1
    kind: KubeletConfiguration
    systemReservedCgroup: ""
    enforceNodeAllocatable:
      - "pods"

다음과 같습니다.

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

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

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

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

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

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

이 노드의 경우 유효 노드 할당 가능 값은 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 종료됩니다.

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

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