7.5. NUMA 인식 스케줄링 문제 해결
NUMA 인식 Pod 예약의 일반적인 문제를 해결하려면 다음 단계를 수행합니다.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc
)를 설치합니다. - cluster-admin 권한이 있는 사용자로 로그인합니다.
- NUMA Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.
프로세스
다음 명령을 실행하여
noderesourcetopologies
CRD가 클러스터에 배포되었는지 확인합니다.$ oc get crd | grep noderesourcetopologies
출력 예
NAME CREATED AT noderesourcetopologies.topology.node.k8s.io 2022-01-18T08:28:06Z
다음 명령을 실행하여 NUMA 인식 스케줄러 이름이 NUMA 인식 워크로드에 지정된 이름과 일치하는지 확인합니다.
$ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
출력 예
topo-aware-scheduler
NUMA 인식 가능 노드에
noderesourcetopologies
CR이 적용되는지 확인합니다. 다음 명령을 실행합니다.$ oc get noderesourcetopologies.topology.node.k8s.io
출력 예
NAME AGE compute-0.example.com 17h compute-1.example.com 17h
참고노드 수는 머신 구성 풀(
mcp
) 작업자 정의로 구성된 작업자 노드 수와 같아야 합니다.다음 명령을 실행하여 예약 가능한 모든 노드에 대한 NUMA 영역 단위를 확인합니다.
$ oc get noderesourcetopologies.topology.node.k8s.io -o yaml
출력 예
apiVersion: v1 items: - apiVersion: topology.node.k8s.io/v1 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/v1 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: ""
7.5.1. 보다 정확한 리소스 가용성 보고
cacheResyncPeriod
사양을 활성화하여 노드에서 보류 중인 리소스를 모니터링하고 이 정보를 정의된 간격으로 스케줄러 캐시에서 동기화하여 NUMA 리소스 가용성을 보다 정확하게 보고할 수 있습니다. 또한 최적의 스케줄링 결정으로 인해 토폴로지 선호도 오류 오류를 최소화하는 데 도움이 됩니다. 간격이 낮으면 네트워크가 더 많이 로드됩니다. cacheResyncPeriod
사양은 기본적으로 비활성화되어 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
현재 실행 중인
NUMAResourcesScheduler
리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler
를 가져옵니다.$ oc get NUMAResourcesScheduler
출력 예
NAME AGE numaresourcesscheduler 92m
다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
$ oc delete NUMAResourcesScheduler numaresourcesscheduler
출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
nro-scheduler-cacheresync.yaml
파일에 다음 YAML을 저장합니다. 이 예에서는 로그 수준을Debug
로 변경합니다.apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesScheduler metadata: name: numaresourcesscheduler spec: imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.15" cacheResyncPeriod: "5s" 1
- 1
- 스케줄러 캐시의 동기화를 위해 간격 값을 초 단위로 입력합니다. 값
5s
는 대부분의 구현에 일반적인 값입니다.
다음 명령을 실행하여 업데이트된
NUMAResourcesScheduler
리소스를 만듭니다.$ oc create -f nro-scheduler-cacheresync.yaml
출력 예
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
검증 단계
NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.
다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.
$ oc get crd | grep numaresourcesschedulers
출력 예
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.
$ oc get numaresourcesschedulers.nodetopology.openshift.io
출력 예
NAME AGE numaresourcesscheduler 3h26m
스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.
다음 명령을 실행하여
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
다음 명령을 실행하여 보조 스케줄러 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"
7.5.2. NUMA 인식 스케줄러 로그 확인
로그를 검토하여 NUMA 인식 스케줄러의 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler
리소스의 spec.logLevel
필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal
,Debug
및 Trace
이며 Trace
는 가장 자세한 옵션입니다.
보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 다시 배포합니다. 이 다운타임 동안 새 워크로드를 예약할 수 없습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
현재 실행 중인
NUMAResourcesScheduler
리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler
를 가져옵니다.$ oc get NUMAResourcesScheduler
출력 예
NAME AGE numaresourcesscheduler 90m
다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
$ oc delete NUMAResourcesScheduler numaresourcesscheduler
출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
nro-scheduler-debug.yaml
파일에 다음 YAML을 저장합니다. 이 예에서는 로그 수준을Debug
로 변경합니다.apiVersion: nodetopology.openshift.io/v1 kind: NUMAResourcesScheduler metadata: name: numaresourcesscheduler spec: imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.15" logLevel: Debug
다음 명령을 실행하여 업데이트된
Debug
loggingNUMAResourcesScheduler
리소스를 만듭니다.$ oc create -f nro-scheduler-debug.yaml
출력 예
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
검증 단계
NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.
다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.
$ oc get crd | grep numaresourcesschedulers
출력 예
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.
$ oc get numaresourcesschedulers.nodetopology.openshift.io
출력 예
NAME AGE numaresourcesscheduler 3h26m
스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.
다음 명령을 실행하여
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
다음 명령을 실행하여 보조 스케줄러 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"
7.5.3. 리소스 토폴로지 내보내기 문제 해결
해당 resource-topology-exporter
로그를 검사하여 예기치 않은 결과가 발생하는 noderesourcetopologies
오브젝트의 문제를 해결합니다.
해당 노드에서 클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름을 지정하는 것이 좋습니다. 예를 들어, 이름이 worker인 작업자 노드에는
라는 해당 worker
noderesourcetopologies
오브젝트가 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
NUMA Resources Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는
NUMAResourcesOperator
CR에 해당nodeGroup
이 있습니다. 다음 명령을 실행합니다.$ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"
출력 예
{"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}
이전 단계의
name
에 대한 값을 사용하여 관심 있는 데몬 세트의 레이블을 가져옵니다.$ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"
출력 예
{"name":"resource-topology"}
다음 명령을 실행하여
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
문제 해결 중인 노드에 해당하는 작업자 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
7.5.4. 누락된 리소스 토폴로지 내보내기 구성 맵 수정
클러스터 설정이 잘못 구성된 클러스터에 NUMA Resources Operator를 설치하는 경우 Operator가 active로 표시되지만 RTE(Resource topology exporter) 데몬 세트 Pod의 로그에 RTE의 구성이 누락되어 있음을 보여줍니다.
Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"
이 로그 메시지는 필요한 구성이 있는 kubeletconfig
가 클러스터에 제대로 적용되지 않아 RTE configmap
이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에 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 Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.
프로세스
다음 명령을 사용하여
MachineConfigPool
(mcp
) 작업자 CR의spec.machineConfigPoolSelector.matchLabels
값과kubeletconfig
및metadata.labels
의 값을 비교합니다.다음 명령을 실행하여
kubeletconfig
레이블을 확인합니다.$ oc get kubeletconfig -o yaml
출력 예
machineConfigPoolSelector: matchLabels: cnf-worker-tuning: enabled
다음 명령을 실행하여
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
오브젝트에 없습니다.
누락된 라벨을 포함하도록
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
- 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.
검증
누락된
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
7.5.5. NUMA Resources Operator 데이터 수집
oc adm must-gather
CLI 명령을 사용하여 NUMA Resources Operator와 관련된 기능 및 오브젝트를 포함하여 클러스터에 대한 정보를 수집할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
must-gather
를 사용하여 NUMA Resources Operator 데이터를 수집하려면 NUMA Resources Operatormust-gather
이미지를 지정해야 합니다.$ oc adm must-gather --image=registry.redhat.io/numaresources-must-gather/numaresources-must-gather-rhel9:v4.15