Quiz: That a node has GPUs is written down as labels
한국어 원문으로 표시합니다.
GPU Operator 를 설치했는데 오퍼랜드 파드가 한 개도 뜨지 않고 오류 로그도 없다. 가장 먼저 확인할 것은?
- 노드에 feature.node.kubernetes.io/pci-10de.present 라벨이 붙어 있는지 — 오퍼레이터는 이 라벨로 GPU 워커를 식별한다
- 오퍼레이터 파드의 메모리 요청이 노드 여유보다 큰지 — 오퍼랜드는 오퍼레이터와 한 파드에서 함께 뜬다
- 컨테이너 런타임이 containerd 인지 docker 인지 — 런타임이 다르면 오퍼랜드 데몬셋이 조용히 건너뛰어진다
- 노드의 커널이 드라이버 컨테이너보다 새 판인지 — 판이 어긋나면 오퍼레이터가 배치 자체를 보류한다
nvidia.com/cuda.driver 를 major·minor·rev 세 라벨로 쪼개 붙이는 실질적인 이유는?
- 라벨 값이 63자를 넘을 수 없어서 550.90.07 같은 문자열은 한 라벨에 담기지 않기 때문이다
- nodeAffinity 의 Gt·Lt 가 값을 정수로 읽으므로, 조각으로 나눠야 '드라이버 몇 판 이상' 같은 조건을 적을 수 있다
- 쪼개 두면 GFD 가 라벨 하나만 갱신해도 되어서 노드 오브젝트의 리비전 충돌이 줄어든다
- 라벨 키에 점이 두 개 이상 들어가면 셀렉터 문법이 그것을 경로로 해석해 값을 찾지 못하기 때문이다
nodeAffinity 의 nodeSelectorTerms 와 matchExpressions 의 결합 방식으로 옳은 것은?
- 둘 다 AND 이고, OR 가 필요하면 파드를 나눠 여러 개 만들어야 한다
- 둘 다 OR 이고, AND 가 필요하면 preferred 쪽에 가중치를 나눠 주어야 한다
- term 목록은 OR 이고, 한 term 안의 matchExpressions 는 AND 다
- term 목록은 AND 이고, 한 term 안의 matchExpressions 는 먼저 적은 것이 이긴다
라벨을 요구하는 파드가 잘 돌고 있는 노드에서 그 라벨을 실수로 지웠다. requiredDuringSchedulingIgnoredDuringExecution 을 쓴 경우 무슨 일이 일어나는가?
- 돌던 파드가 곧바로 퇴거되고 조건에 맞는 다른 노드로 다시 스케줄된다
- 돌던 파드에 NodeAffinityMismatch 이벤트가 달리고 다음 재시작 때 퇴거된다
- 돌던 파드가 Pending 으로 바뀌면서 노드에서 분리되지만 컨테이너는 계속 돈다
- 돌던 파드는 그대로 남고, 그 뒤에 새로 만들어지는 파드부터 조건을 못 맞춰 대기한다
드라이버가 알려 주는 모델 이름 NVIDIA A100-SXM4-40GB 를 그대로 노드 라벨 값으로 넣으면 어떻게 되며, GFD 는 이를 어떻게 다루는가?
- API 서버가 값 문법 위반으로 거절하므로, GFD 는 허용되지 않는 문자를 바꾸어 정규화한 이름을 붙인다
- 값은 그대로 저장되지만 셀렉터가 공백에서 끊어 읽으므로, GFD 는 이름을 따옴표로 감싸 붙인다
- API 서버가 공백을 밑줄로 자동 치환해 저장하므로, GFD 는 원본 이름을 그대로 보내면 된다
- 값이 63자를 넘어 잘리므로, GFD 는 모델 이름 대신 PCI 장치 ID 를 라벨 값으로 쓴다
NFD 가 붙인 라벨을 kubectl label --overwrite 로 고쳐 두었는데 얼마 뒤 원래 값으로 돌아왔다. 올바른 대응은?
- nfd-worker 데몬셋의 갱신 주기를 늘려 사람이 고친 값이 유지되는 시간을 확보한다
- 그 노드에 nfd.node.kubernetes.io/ignore 어노테이션을 달아 마스터가 노드를 건드리지 않게 한다
- 발견 라벨은 NFD 의 것이므로 읽기만 하고, 사람이 정하는 사실은 자기 접두사의 라벨에 적거나 NodeFeatureRule 로 NFD 가 붙이게 한다
- nfd-master 에 라벨 화이트리스트를 설정해 그 키를 목록에서 빼면 마스터가 그 라벨을 관리 대상에서 제외한다