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


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

중요

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

5.10.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를 사용하여 할당할 수 없습니다.

5.10.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.10.1.2. 노드에서 리소스 제약 조건을 적용하는 방법

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

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

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

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

5.10.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.10.1.4. 스케줄러에서 리소스 가용성을 결정하는 방법

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

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

5.10.2. 노드의 리소스 자동 할당

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

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

최적의 시스템 예약 설정을 자동으로 결정하면 클러스터가 효율적으로 실행되고 CRI- O 및 kubelet과 같은 시스템 구성 요소의 리소스 부족으로 인해 노드 오류가 발생하지 않도록 합니다.

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

사전 요구 사항

  1. 다음 명령을 입력하여 구성할 노드 유형의 정적 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

절차

  1. 구성 변경을 위한 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
    머신 구성 풀에서 라벨을 지정합니다.

    이전 예제에서는 모든 작업자 노드에서 자동 리소스 할당을 활성화합니다. OpenShift Container Platform은 노드를 드레이닝하고 kubelet 구성을 적용한 다음 노드를 다시 시작합니다.

  2. 다음 명령을 입력하여 CR을 생성합니다.

    $ oc create -f <file_name>.yaml

검증

  1. 다음 명령을 입력하여 구성한 노드에 로그인합니다.

    $ oc debug node/<node_name>
  2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다.

    # chroot /host
  3. /etc/node-sizing.env 파일을 확인합니다.

    출력 예

    SYSTEM_RESERVED_MEMORY=3Gi
    SYSTEM_RESERVED_CPU=0.08

    kubelet은 /etc/node-sizing.env 파일의 system-reserved 값을 사용합니다. 이전 예에서 작업자 노드에 0.08 CPU 및 메모리 3Gi가 할당됩니다. 최적의 값이 표시되는 데 몇 분이 걸릴 수 있습니다.

5.10.3. 노드의 리소스 수동 할당

OpenShift Container Platform은 할당을 위해 CPU 및 메모리 리소스 유형을 지원합니다. ephemeral-resource 리소스 유형도 지원됩니다. cpu 유형의 경우 200m,0.5 또는 1 과 같은 코어 단위로 리소스 수량을 지정합니다. memoryephemeral-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 값을 참조하십시오.

사전 요구 사항

  1. 다음 명령을 입력하여 구성할 노드 유형의 정적 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

프로세스

  1. 구성 변경을 위한 사용자 정의 리소스 (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
    노드 구성 요소 및 시스템 구성 요소에 예약할 리소스를 지정합니다.
  2. 다음 명령을 실행하여 CR을 생성합니다.

    $ oc create -f <file_name>.yaml
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.