kubectl 로는 GPU 가 보이는데 Cloudera AI Inference 의 GPU Node Groups 가 "No Data" 이고 모델 엔드포인트에서 GPU 를 고를 수 없다.
kubectl get node <gpu-node> -o jsonpath='{.status.allocatable.nvidia\.com/gpu}' # 14
kubectl describe node <gpu-node> | grep -i taint # Taints: <none>
Private Cloud(ECS) 는 Public Cloud 처럼 인스턴스 타입과 autoscale 범위를 골라 노드 그룹을 만드는 방식이 아니다. GPU 호스트에 taint 를 걸어 "Data Services 전용 GPU 노드" 로 지정하면 CAI 워크로드가 그 노드에 스케줄된다. Inference 의 GPU 워크로드는 nvidia.com/gpu: true:NoSchedule 에 대한 toleration 을 갖고 동작하므로 노드에 이 taint 가 있어야 GPU 노드로 인식된다.
운영 중인 클러스터에서의 절차는 다음과 같다.
node_taint 를 찾아 Dedicated GPU Node 체크(다른 워크로드 파드는 이 노드에서 실행되지 않는다)kubectl describe node <gpu-node> | grep -i taint
# nvidia.com/gpu=true:NoSchedule
Taints: <none> 은 오류가 아니라 아직 설정하지 않은 상태다. 위 절차 후에 값이 생긴다. Cloudera Manager 에서 node_taint 항목이 보이지 않는다면 일반 서비스 Configuration 화면이 아니라 ECS 클러스터의 Hosts 에서 호스트를 선택한 뒤의 Configuration 탭인지 확인한다. ECS 는 NVIDIA Feature Discovery 로 GPU 노드 라벨이 자동 생성되므로 라벨은 대개 이미 잡혀 있고 빠진 것은 taint 인 경우가 많다(OCP 는 수동 구성 필요).
Cloudera AI 1.5.5 on-premises requirements 의 "Limitations on Cloudera on premises" 는 Cloudera AI 가 NVIDIA MIG 를 지원하지 않는다고 명시한다. 노드 라벨이 MIG 구성을 드러내면 Inference service 가 그 노드를 지원 대상이 아니라고 보고 GPU Node Group 에 등록하지 않는다.
nvidia.com/gpu.count=2 물리 A100 80GB 2장
nvidia.com/gpu.product=NVIDIA-A100-80GB-PCIe
nvidia.com/mig.capable=true
allocatable nvidia.com/gpu: 14 2 × 7 MIG 슬라이스
nvidia-smi -L
nvidia-smi mig -lgi
kubectl get node <gpu-node> -o jsonpath='{.metadata.labels.nvidia\.com/mig\.config}{"\n"}'
여기서 중요한 구분이 하나 있다. Workbench 는 세션 · 모델 파드를 노드에 직접 띄우면서 nvidia.com/gpu 를 요청하므로 single strategy 로 14개가 광고되면 슬라이스 하나에 그냥 스케줄된다. 그래서 Workbench 화면에는 MIG 로 쪼개진 GPU 가 보인다. 반면 Inference service 는 KServe 기반에 자체 GPU Node Group 추상화로 GPU 노드를 따로 인식 · 등록하므로 경로가 다르다. UI 에 보이는 것과 지원되는 것은 별개다.
MIG 를 GPU Operator(mig-manager) 가 관리한다면 호스트에서 nvidia-smi 로 꺼도 되돌려지므로 nvidia.com/mig.config 라벨을 all-disabled 로 바꿔야 한다.
| 방향 | 내용 |
|---|---|
| MIG 를 끄고 풀 A100 2장으로 | 지원되는 유일한 경로. 80GB 한 장이면 큰 NIM/LLM 이 올라가고, 동시 2개 엔드포인트 또는 replica 로 운용한다 |
| raw KServe 로 MIG 슬라이스에 직접 올리기 | 기술적으로는 InferenceService 에 nvidia.com/gpu: 1 과 toleration 을 주면 스케줄된다. 다만 Knox 인증 엔드포인트, CAI UI 관리(autoscale · canary · 트래픽 분할), AI Registry 연동, Atlas 거버넌스, 지원을 모두 포기한다. serving-default 같은 CAI 관리 네임스페이스에 직접 만들면 컨트롤 플레인이 reconcile 하며 충돌하거나 지울 수 있다 |
| Cloudera 에 확인 | MIG 미지원 문구는 Workbench 중심 requirements 문서의 플랫폼 제약이고 Inference service 는 별도 버전 체계를 갖는다. 정식 확인이 필요하다 |
KServe 는 학습된 모델을 API 로 서빙하는 CNCF 오픈소스로, 모델 로딩 · 추론 API · 오토스케일(scale-to-zero) · 버전 관리 · 카나리를 InferenceService 리소스 하나로 추상화한다. Cloudera AI Inference service 는 그 위에 인증 · UI · 모델 레지스트리 · 거버넌스 · NVIDIA NIM 런타임을 얹은 것이다. 네임스페이스로 보면 kserve(컨트롤러), knative-serving(오토스케일 엔진), istio-system/istio-ingress(라우팅), serving-default(엔드포인트가 배포되는 곳), knox-caii(인증 게이트웨이) 가 한 벌로 동작한다. CAI UI 에서 엔드포인트를 만들면 내부적으로 serving-default 에 InferenceService 가 생긴다.
3노드(control-plane 1, worker 2) 구성에서 워커 한 대를 GPU 전용으로 지정하면 그 노드의 일반 파드가 쫓겨나 나머지 워커 한 대로 몰린다. 다만 이 사례에서는 kubectl top node 상 세 노드 모두 CPU 0~11%, 메모리 5~14% 로 한가했고, 재기동 직후 Pending · CrashLoop 이 많이 보인 것은 용량 문제가 아니라 안정화 과정이었다. age 가 1초인 Pending, 1/2·0/2 패턴(istiod 가 아직 안 올라와 사이드카가 CrashLoop), -0 으로 끝나는 StatefulSet 파드의 Pending(Longhorn 복구 중 PVC 바인딩 대기) 이 그 신호다.
watch "kubectl get pods -A | grep -vE 'Running|Completed'"
kubectl get pods -n longhorn-system
kubectl get pods -A | grep -iE 'istio|istiod'
kubectl describe node <worker> | grep -A8 "Allocated resources"
10~20분이 지나도 풀리지 않으면 멈춘 파드를 콕 집어 describe 로 Events 를 본다.
MIG 를 유지한 채 Inference service 에 GPU Node Group 을 등록하는 지원 경로는 찾지 못했고, MIG 비활성화나 raw KServe 시도 결과는 대화에 남아 있지 않다.