6.6. NUMA 인식 스케줄링 문제 해결

NUMA 인식 Pod 예약과 관련된 일반적인 문제를 해결하려면 다음 단계를 수행합니다.

사전 요구 사항

  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NUMA 리소스 Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.

절차

  1. 다음 명령을 실행하여 noderesourcetopologies CRD가 클러스터에 배포되었는지 확인합니다. 

    $ oc get crd | grep noderesourcetopologies

    출력 예

    NAME                                                              CREATED AT
noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

  2. NUMA 인식 스케줄러 이름이 다음 명령을 실행하여 NUMA 인식 워크로드에 지정된 이름과 일치하는지 확인합니다. 

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

    출력 예

    topo-aware-scheduler

  3. NUMA가 인식 가능한 노드에 noderesourcetopologies CR이 적용되는지 확인합니다. 다음 명령을 실행합니다. 

    $ oc get noderesourcetopologies.topology.node.k8s.io

    출력 예

    NAME                    AGE
compute-0.example.com   17h
compute-1.example.com   17h

    참고

    노드 수는 머신 구성 풀(mcp) 작업자 정의로 구성된 작업자 노드 수와 같아야 합니다.

  4. 다음 명령을 실행하여 모든 측정 가능한 노드에 대한 NUMA 영역 세분성을 확인합니다. 

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

    출력 예

    apiVersion: v1
items:
- apiVersion: topology.node.k8s.io/v1alpha1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:38Z"
    generation: 63760
    name: worker-0
    resourceVersion: "8450223"
    uid: 8b77be46-08c0-4074-927b-d49361471590
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones:
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources:
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262352048128"
      available: "262352048128"
      capacity: "270107316224"
      name: memory
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269231067136"
      available: "269231067136"
      capacity: "270573244416"
      name: memory
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    type: Node
- apiVersion: topology.node.k8s.io/v1alpha1
  kind: NodeResourceTopology
  metadata:
    annotations:
      k8stopoawareschedwg/rte-update: periodic
    creationTimestamp: "2022-06-16T08:55:37Z"
    generation: 62061
    name: worker-1
    resourceVersion: "8450129"
    uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
  topologyPolicies:
  - SingleNUMANodeContainerLevel
  zones: 1
  - costs:
    - name: node-0
      value: 10
    - name: node-1
      value: 21
    name: node-0
    resources: 2
    - allocatable: "38"
      available: "38"
      capacity: "40"
      name: cpu
    - allocatable: "6442450944"
      available: "6442450944"
      capacity: "6442450944"
      name: hugepages-1Gi
    - allocatable: "134217728"
      available: "134217728"
      capacity: "134217728"
      name: hugepages-2Mi
    - allocatable: "262391033856"
      available: "262391033856"
      capacity: "270146301952"
      name: memory
    type: Node
  - costs:
    - name: node-0
      value: 21
    - name: node-1
      value: 10
    name: node-1
    resources:
    - allocatable: "40"
      available: "40"
      capacity: "40"
      name: cpu
    - allocatable: "1073741824"
      available: "1073741824"
      capacity: "1073741824"
      name: hugepages-1Gi
    - allocatable: "268435456"
      available: "268435456"
      capacity: "268435456"
      name: hugepages-2Mi
    - allocatable: "269192085504"
      available: "269192085504"
      capacity: "270534262784"
      name: memory
    type: Node
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

    1
    영역 의 각 스탠자는 단일 NUMA 영역의 리소스를 설명합니다.
    2
    리소스 는 NUMA 영역 리소스의 현재 상태를 설명합니다. items.zones.resources.available 에 나열된 리소스가 각 보장된 pod에 할당된 독점 NUMA 영역 리소스와 일치하는지 확인합니다.

6.6.1. NUMA 인식 스케줄러 로그 확인

로그를 검토하여 NUMA 인식 스케줄러에서 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler 리소스의 spec.logLevel 필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal,Debug 및 Trace 이며 Trace 는 가장 자세한 정보 옵션입니다.

참고

보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 재배포합니다. 이 다운타임 동안 새 워크로드를 예약하는 데 스케줄러를 사용할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. 현재 실행 중인 NUMAResourcesScheduler 리소스를 삭제합니다.

    1. 다음 명령을 실행하여 활성 NUMAResourcesScheduler 를 가져옵니다. 

      $ oc get NUMAResourcesScheduler

      출력 예

      NAME                     AGE
numaresourcesscheduler   90m

    2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다. 

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      출력 예

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 다음 YAML을 nro-scheduler-debug.yaml 파일에 저장합니다. 이 예제에서는 로그 수준을 Debug 로 변경합니다. 

    apiVersion: nodetopology.openshift.io/v1alpha1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"
  logLevel: Debug

  3. 다음 명령을 실행하여 업데이트된 Debug logging NUMAResourcesScheduler 리소스를 생성합니다. 

    $ oc create -f nro-scheduler-debug.yaml

    출력 예

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

검증 단계

  1. NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 CRD가 적절하게 생성되었는지 확인합니다. 

      $ oc get crd | grep numaresourcesschedulers

      출력 예

      NAME                                                              CREATED AT
numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다. 

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      출력 예

      NAME                     AGE
numaresourcesscheduler   3h26m

  2. 스케줄러의 로그에 로그 수준이 증가되었는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다. 

      $ oc get pods -n openshift-numaresources

      출력 예

      NAME                                               READY   STATUS    RESTARTS   AGE
numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m

    2. 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다. 

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      출력 예

      ...
I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

6.6.2. 리소스 토폴로지 내보내기 문제 해결

해당 resource-topology-exporter 로그를 검사하여 예기치 않은 결과가 발생하는 noderesourcetopologies 오브젝트의 문제를 해결합니다.

참고

클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름을 참조하는 노드의 이름을 지정하는 것이 좋습니다. 예를 들어 이름이 worker인 작업자 노드에는 worker 라는 해당 noderesourcetopologies 오브젝트가 있어야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. NUMA 리소스 Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는 NUMAResourcesOperator CR에 해당 nodeGroup 이 있습니다. 다음 명령을 실행합니다. 

    $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"

    출력 예

    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}

  2. 이전 단계의 이름 값을 사용하여 관심 있는 daemonset의 레이블을 가져옵니다. 

    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

    출력 예

    {"name":"resource-topology"}

  3. 다음 명령을 실행하여 resource-topology 레이블을 사용하여 Pod를 가져옵니다. 

    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

    출력 예

    NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com

  4. 문제 해결 노드에 해당하는 작업자 Pod에서 실행되는 resource-topology-exporter 컨테이너의 로그를 검사합니다. 다음 명령을 실행합니다. 

    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

    출력 예

    I0221 13:38:18.334140       1 main.go:206] using sysinfo:
reservedCpus: 0,1
reservedMemory:
  "0": 1178599424
I0221 13:38:18.334370       1 main.go:67] === System information ===
I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
I0221 13:38:18.546750       1 main.go:72]
cpus: allocatable "2-103"
hugepages-1Gi:
  numa cell 0 -> 6
  numa cell 1 -> 1
hugepages-2Mi:
  numa cell 0 -> 64
  numa cell 1 -> 128
memory:
  numa cell 0 -> 45758Mi
  numa cell 1 -> 48372Mi

6.6.3. 누락된 리소스 토폴로지 내보내기 구성 맵 수정

경우에 따라 클러스터 설정이 잘못 구성된 클러스터에 NUMA 리소스 Operator를 설치하는 경우 Operator가 활성으로 표시되지만 리소스 토폴로지 내보내기(RTE) 데몬 세트 Pod의 로그에 RTE의 구성이 누락된 것으로 표시됩니다. 

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

이 로그 메시지는 필요한 구성이 있는 kubeletconfig 가 클러스터에 제대로 적용되지 않아 RTE 구성 맵이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에는 numaresourcesoperator-worker configmap CR(사용자 정의 리소스)이 없습니다. 

$ oc get configmap

출력 예

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

올바르게 구성된 클러스터에서 oc get configmap 도 numaresourcesoperator-worker configmap CR을 반환합니다.

사전 요구 사항

  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NUMA 리소스 Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.

절차

  1. 다음 명령을 사용하여 kubeletconfig 의 spec.machineConfigPoolSelector.matchLabels 값과 MachineConfigPool (mcp) worker CR의 metadata.labels 값을 비교합니다.

    1. 다음 명령을 실행하여 kubeletconfig 라벨을 확인합니다. 

      $ oc get kubeletconfig -o yaml

      출력 예

      machineConfigPoolSelector:
  matchLabels:
    cnf-worker-tuning: enabled

    2. 다음 명령을 실행하여 mcp 레이블을 확인합니다. 

      $ oc get mcp worker -o yaml

      출력 예

      labels:
  machineconfiguration.openshift.io/mco-built-in: ""
  pools.operator.machineconfiguration.openshift.io/worker: ""

      cnf-worker-tuning: enabled 레이블은 MachineConfigPool 오브젝트에 존재하지 않습니다.

  2. 누락된 레이블을 포함하도록 MachineConfigPool CR을 편집합니다. 예를 들면 다음과 같습니다. 

    $ oc edit mcp worker -o yaml

    출력 예

    labels:
  machineconfiguration.openshift.io/mco-built-in: ""
  pools.operator.machineconfiguration.openshift.io/worker: ""
  cnf-worker-tuning: enabled

  3. 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.

검증

  • 누락된 numaresourcesoperator-worker configmap CR이 적용되었는지 확인합니다. 

    $ oc get configmap

    출력 예

    NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
numaresourcesoperator-worker   1      5m
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h