이 페이지에서는 Google Kubernetes Engine(GKE)에서 GPU와 관련된 문제를 해결하는 방법을 설명합니다.
GPU 드라이버 설치
이 섹션에서는 GKE의 자동 NVIDIA 기기 드라이버 설치에 대한 문제 해결 정보를 제공합니다.
Ubuntu 노드에서 드라이버 설치 실패
L4, H100, 또는 H200 GPU가 연결된 Ubuntu 노드를 사용하는 경우 GKE에서 설치하는 기본 GPU 드라이버가 해당 GPU에 필요한 버전보다 낮을 수 있습니다. 그 결과 GPU 기기 플러그인 포드가 대기 중 상태로 멈추고 해당 노드의 GPU 워크로드에 문제가 발생할 수 있습니다.
L4 및 H100 GPU의 이 문제를 해결하려면 GPU 드라이버 버전 535를 기본 드라이버로 설치하는 다음 GKE 버전으로 업그레이드하는 것이 좋습니다.
- 1.26.15-gke.1483000 이상
- 1.27.15-gke.1039000 이상
- 1.28.11-gke.1044000 이상
- 1.29.6-gke.1073000 이상
- 1.30.2-gke.1124000 이상
또는 다음 명령어를 실행하여 드라이버 버전 535 이상을 수동으로 설치할 수 있습니다.
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml
H200 GPU의 이 문제를 해결하려면 다음 명령어를 실행하여 드라이버 버전 550 이상을 수동으로 설치해야 합니다.
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml
GPU 기기 플러그인이 CrashLoopBackOff 오류와 함께 실패
2023년 1월 25일 이전에 노드 풀에서 수동 드라이버 설치 메서드를 사용한 후 노드 풀을 자동 드라이버를 지원하는 GKE 버전으로 업그레이드한 경우 다음과 같은 문제가 발생합니다. 두 설치 워크로드가 동시에 존재하며 노드에 충돌하는 드라이버 버전을 설치하려고 합니다.
GPU 기기 플러그인 초기화 컨테이너가 Init:CrashLoopBackOff
상태로 실패합니다. 컨테이너의 로그는 다음과 비슷합니다.
failed to verify installation: failed to verify GPU driver installation: exit status 18
이 문제를 해결하려면 다음을 메서드를 시도해 보세요.
클러스터에서 수동 드라이버 설치 DaemonSet를 삭제합니다. 이렇게 하면 충돌하는 설치 워크로드가 삭제되고 GKE가 노드에 드라이버를 자동으로 설치할 수 있습니다.
kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
수동 드라이버 설치 DaemonSet 매니페스트를 클러스터에 다시 적용합니다. 2023년 1월 25일에 자동 드라이버 설치를 사용하는 노드를 무시하도록 매니페스트가 업데이트되었습니다.
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
노드 풀의 자동 드라이버 설치를 사용 중지합니다. 업데이트 작업이 완료된 후 기존 드라이버 설치 DaemonSet가 예상대로 작동해야 합니다.
gcloud container node-pools update POOL_NAME \ --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \ --cluster=CLUSTER_NAME \ --location=LOCATION
다음을 바꿉니다.
POOL_NAME
: 노드 풀의 이름입니다.GPU_TYPE
: 노드 풀에서 이미 사용 중인 GPU 유형입니다.GPU_COUNT
: 노드 풀에 이미 연결된 GPU 수입니다.CLUSTER_NAME
: 노드 풀이 포함된 GKE 클러스터의 이름입니다.LOCATION
: 클러스터의 Compute Engine 위치입니다.
GPU 드라이버 버전을 GKE 버전에 매핑하는 방법에 대한 자세한 내용은 GKE 버전 및 Container-Optimized OS 노드 이미지 버전을 GPU 드라이버 버전에 매핑을 참고하세요.
오류: '컨테이너 이미지 cos-nvidia-installer:fixed가 가져오기 정책이 '사용 안함'인 경우 존재하지 않습니다.' 또는 '컨테이너 이미지 ubuntu-nvidia-installer:fixed가 가져오기 정책이 '사용 안함'인 경우 존재하지 않습니다.'
이 문제는 nvidia-driver-installer
포드가 PodInitializing
상태이고 GPU 플러그인 기기 또는 GPU 드라이버 설치 프로그램 포드가 다음 오류를 보고하는 경우에 발생합니다. 구체적인 오류 메시지는 노드에서 실행되는 운영체제에 따라 다릅니다.
COS
Container image "cos-nvidia-installer:fixed" is not present with pull policy of Never.
Ubuntu
Container image "gke-nvidia-installer:fixed" is not present with pull policy of Never.
이 문제는 가비지 수집기가 노드의 공간을 확보하기 위해 미리 로드된 NVIDIA 드라이버 이미지를 삭제할 때 발생할 수 있습니다. 드라이버 포드가 다시 생성되거나 컨테이너가 다시 시작되면 GKE에서 미리 로드된 이미지를 찾을 수 없습니다.
COS를 실행할 때 발생하는 가비지 컬렉션 문제를 완화하려면 수정사항이 포함된 다음 버전 중 하나로 GKE 노드를 업그레이드하세요.
- 1.25.15-gke.1040000 이상
- 1.26.10-gke.1030000 이상
- 1.27.6-gke.1513000 이상
- 1.28.3-gke.1061000 이상
GPU 드라이버 버전을 GKE 버전에 매핑하는 방법에 대한 자세한 내용은 GKE 버전 및 Container-Optimized OS 노드 이미지 버전을 GPU 드라이버 버전에 매핑을 참고하세요.
노드에서 Ubuntu를 실행하는 경우 이 가비지 컬렉션 문제에 대한 해결 방법은 아직 없습니다. Ubuntu에서 이 문제를 완화하려면 호스트와 상호작용하여 NVIDIA GPU 드라이버가 올바르게 설정되도록 하는 권한이 있는 컨테이너를 실행하면 됩니다. 이렇게 하려면 노드에서 sudo /usr/local/bin/nvidia-container-first-boot
를 실행하거나 다음 매니페스트를 적용합니다.
apiVersion: v1
kind: Pod
metadata:
name: gke-nvidia-installer-fixup
spec:
nodeSelector:
cloud.google.com/gke-os-distribution: ubuntu
hostPID: true
containers:
- name: installer
image: ubuntu
securityContext:
privileged: true
command:
- nsenter
- -at
- '1'
- --
- sh
- -c
- "/usr/local/bin/nvidia-container-first-boot"
restartPolicy: Never
노드 재부팅 또는 호스트 유지보수 후 NVIDIA 드라이버 이미지가 손실되는 경우에도 이 문제가 발생할 수 있습니다. 이는 임시 로컬 SSD 스토리지를 사용하는 컨피덴셜 노드 또는 GPU가 있는 노드에서 발생할 수 있습니다. 이 경우 GKE는 노드에 nvidia-installer-driver
컨테이너 이미지를 미리 로드하고 첫 부팅 시 부팅 디스크에서 로컬 SSD로 이동합니다.
호스트 유지보수 이벤트가 있었는지 확인하려면 다음 로그 필터를 사용하세요.
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")
호스트 유지보수 문제를 완화하려면 GKE 버전을 다음 버전 중 하나로 업그레이드하세요.
- 1.27.13-gke.1166000 이상
- 1.29.3-gke.1227000 이상
- 1.28.8-gke.1171000 이상
오류: GPU 드라이버 설치 디렉터리를 구성하지 못했습니다. lib64 오버레이를 만들지 못했습니다. /usr/local/nvidia/lib64 디렉터리를 만들지 못했습니다. mkdir /usr/local/nvidia/lib64: 디렉터리가 아닙니다.
NCCL fastsocket이 사용 설정된 경우 GPU 기기 플러그인 내의 GPU 드라이버 설치 프로그램 컨테이너에서 다음 오류가 발생합니다.
failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.
이 문제는 GKE 1.28 및 1.29를 실행하는 클러스터와 노드에서만 발생합니다.
이 문제는 GPU 드라이버 설치 프로그램과 NCCL fastsocket 경합 상태로 인해 발생합니다.
이 문제를 완화하려면 GKE 버전을 다음 버전 중 하나로 업그레이드하세요.
- 1.28.8-gke.1206000 이상
- 1.29.3-gke.1344000 이상
자세한 내용은 GPUDirect-TCPXO 출시 노트를 참고하세요.
오류: nvidia0의 기기를 가져오지 못했습니다. nvidia0 기기를 찾을 수 없습니다.
다음 오류는 마이너 0이 있는 GPU에 대해 XID 62 및 RmInitAdapter가 실패했음을 나타냅니다.
Failed to get device for nvidia0: device nvidia0 not found.
NVIDIA 드라이버 버전 525.105.17에는 통신 오류(XID)를 일으키고 GPU가 제대로 초기화되지 않아 GPU 초기화에 실패할 수 있는 버그가 있습니다.
이 문제를 해결하려면 NVIDIA 드라이버를 드라이버 버전 525.110.11 이상으로 업그레이드하세요.
GKE 버전 및 Container-Optimized OS 노드 이미지 버전을 GPU 드라이버 버전에 매핑합니다.
GKE 버전 및 Container-Optimized OS 노드 이미지 버전과 매핑된 GPU 드라이버 버전을 찾으려면 다음 단계를 따르세요.- GPU 드라이버 버전을 찾으려는 특정 GKE 버전에 대해 Container-Optimized OS 노드 이미지 버전을 GKE 패치 버전에 매핑합니다. 예를 들어 1.33.0-gke.1552000은 cos-121-18867-90-4를 사용합니다.
- Container-Optimized OS 출시 노트에서 Container-Optimized OS 노드 이미지 버전의 마일스톤을 선택합니다. 예를 들어 cos-121-18867-90-4의 경우 마일스톤 121을 선택합니다.
- 특정 마일스톤의 출시 노트 페이지에서 특정 Container-Optimized OS 노드 이미지 버전에 해당하는 출시 노트를 찾습니다. 예를 들어 Container-Optimized OS 출시 노트: 마일스톤 121에서 cos-121-18867-90-4를 참고하세요. GPU 드라이버 열의 표에서 목록 보기를 클릭하여 GPU 드라이버 버전 정보를 확인합니다.
A3 VM에서 GPU 재설정
일부 문제에서는 A3 VM에서 GPU를 재설정해야 할 수 있습니다.
GPU를 재설정하려면 다음 단계를 따르세요.
GPU를 재설정해야 하는 노드에서 GPU 리소스를 요청하는 포드를 삭제합니다.
노드에서 GPU 기기 플러그인을 사용 중지합니다.
kubectl get nodes \ --selector=kubernetes.io/hostname=NODE_NAME \ --no-headers | awk '{print $1}' \ | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=true
NODE_NAME
을 허브 이름으로 바꿉니다.노드를 지원하는 VM에 연결합니다.
SSH 세션에서 GPU를 재설정합니다.
/home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset
GPU 기기 플러그인을 다시 사용 설정합니다.
kubectl get nodes --selector=kubernetes.io/hostname=NODE_NAME \ --no-headers \| awk '{print $1}' \ | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=false \ --overwrite
Confidential GKE Node의 GPU
다음 섹션에서는 컨피덴셜 GKE 노드에서 실행되는 GPU의 문제를 식별하고 수정하는 방법을 보여줍니다.
Confidential GKE Node에서 GPU 워크로드가 예약되지 않음
Confidential GKE Node를 사용하려면 선택한 GPU 유형 및 GKE 버전에 해당하는 GPU 드라이버를 수동으로 설치해야 합니다.
GPU 포드가 Confidential GKE Node에 예약되지 않고 Pending
상태로 유지되는 경우 드라이버 설치 DaemonSet을 설명합니다.
kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml
출력에서 NotFound
오류가 반환되면 드라이버를 설치하세요.
DaemonSet가 실행 중이면 출력은 다음과 비슷합니다.
apiVersion: apps/v1
kind: DaemonSet
# lines omitted for clarity
spec:
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: nvidia-driver-installer
template:
metadata:
creationTimestamp: null
labels:
k8s-app: nvidia-driver-installer
name: nvidia-driver-installer
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/gke-accelerator
operator: Exists
- key: cloud.google.com/gke-gpu-driver-version
operator: DoesNotExist
- key: cloud.google.com/gke-confidential-nodes-instance-type
operator: In
values:
- TDX
이 출력에서 nodeAffinity
필드에 cloud.google.com/gke-confidential-nodes-instance-type
키가 포함되어 있는지 확인합니다. 출력에 이 키가 포함되지 않으면 드라이버 설치 DaemonSet이 Confidential GKE Node를 지원하지 않는 것입니다.
Confidential GKE Node에 GPU를 지원하는 DaemonSet을 배포하세요.
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml
드라이버를 설치한 후 GPU 워크로드가 성공적으로 시작되는지 확인합니다.
오류: 기기 벡터를 할당할 수 없음
GPU 컨테이너 로그에 다음 오류 메시지가 표시되면 GPU가 노드 VM 인스턴스에서 분리되었음을 나타냅니다.
Failed to allocate device vector A (error code unknown error)!
이 분리는 하드웨어 오류 또는 암호화 키 문제로 인해 발생할 수 있습니다.
이 문제를 해결하려면 노드 인스턴스를 재부팅하세요. 이 작업은 중단되며 해당 노드의 모든 워크로드에 영향을 미칩니다. 인스턴스를 재부팅하려면 다음 단계를 따르세요.
GPU 포드를 실행하는 노드의 이름을 가져옵니다.
kubectl get pod POD_NAME -o yaml | grep "nodeName"
POD_NAME
을 실패한 포드의 이름으로 바꿉니다.출력은 다음과 비슷합니다.
nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e
Compute Engine 인스턴스를 재설정합니다.
gcloud compute instances reset NODE_NAME
NODE_NAME
을 이전 단계의 출력에 있는 노드 이름으로 바꿉니다.gcloud CLI는 활성 프로젝트에서 해당 이름의 VM을 찾습니다. 영역을 선택하라는 메시지가 표시되면
Y
를 지정합니다.GPU 워크로드가 오류 없이 실행되는지 확인합니다.
오류: 오류 -74로 인해 복호화에 실패함
노드 로그에 다음 오류 메시지가 표시되면 GPU의 암호화 키가 손실되었음을 나타냅니다.
Decryption failed with error -74
이 오류는 노드 VM 인스턴스에서 실행되는 NVIDIA 지속성 데몬이 실패할 때 발생합니다. 이 오류 메시지가 표시되면 인스턴스를 재설정하세요.
gcloud compute instances reset NODE_NAME
NODE_NAME
을 실패한 노드의 이름으로 바꿉니다.
gcloud CLI는 활성 프로젝트에서 해당 이름의 VM을 찾습니다. 영역을 선택하라는 메시지가 표시되면 Y
를 지정합니다.
인스턴스를 재설정해도 이 문제가 해결되지 않으면 Cloud Customer Care에 문의하거나 제품 버그를 제출하세요. 자세한 내용은 지원 받기를 참조하세요.
XID 오류 찾기
gpu-device-plugin
daemonset은 kube-system
네임스페이스 내에서 실행되며 다음을 담당합니다.
- GPU 워크로드 예약: 포드에 GPU 리소스를 할당합니다.
- GPU 상태 점검: GPU 상태를 모니터링합니다.
- GPU 측정항목 수집: 가동 주기, 메모리 사용량과 같은 GPU 관련 측정항목을 수집합니다.
gpu-device-plugin
는 NVIDIA 관리 라이브러리 (NVML)를 사용하여 XID 오류를 감지합니다. XID 오류가 발생하면 영향을 받는 노드에서 실행되는 gpu-device-plugin
포드가 오류를 로깅합니다. 다음 두 가지 유형의 XID 오류 로그가 표시됩니다.
- 중요하지 않은 XID 오류:
- 로그 형식:
Skip error Xid=%d as it is not Xid Critical
- 의미: 이러한 오류는 중요하지 않은 것으로 간주됩니다. 다양한 소프트웨어 또는 하드웨어 문제로 인해 발생할 수 있습니다.
- 작업: GKE는 심각하지 않은 XID 오류에 대해 자동 작업을 취하지 않습니다.
- 로그 형식:
- 심각한 XID 오류:
- 로그 형식:
XidCriticalError: Xid=%d, All devices will go unhealthy
- 의미: 이 오류는 GPU 하드웨어 문제를 나타냅니다.
- 작업:
- GKE는 노드의 GPU 리소스를 비정상으로 표시합니다.
- GKE는 GPU 워크로드가 노드에 예약되지 않도록 합니다.
- 노드 자동 복구가 사용 설정된 경우 GKE가 노드를 다시 만듭니다.
- 로그 형식:
GPUDirect-TCPX(O) 문제
이 섹션에서는 GPUDirect-TCPX(O) 문제에 대한 문제 해결 정보를 제공합니다.
출시 노트 및 업그레이드 안내
신규 사용자의 경우 Standard 모드 클러스터에서 GPU 네트워크 대역폭 극대화에서 GPUDirect-TCPX(O) 사용에 관한 안내를 확인할 수 있습니다. 기존 사용자의 경우 새 버전이 계속 출시되므로 GPUDirect-TCPXO 출시 노트에서 출시 정보와 업그레이드 안내를 확인하세요.
NCCL 로그로 디버그
NCCL 문제를 해결할 수 없는 경우 디버깅 정보와 함께 NCCL 로그를 수집하세요. 이러한 로그에는 NCCL 작업에 관한 유용한 정보가 포함되어 있으며 문제의 원인을 찾는 데 도움이 될 수 있습니다. 문제를 해결할 수 없는 경우 Cloud Customer Care에 케이스를 접수하기 전에 이러한 로그를 수집하세요. 이러한 로그는 Cloud 고객 관리팀이 문제를 더 빠르게 해결하는 데 도움이 됩니다.
로그를 생성하고 수집하려면 다음 단계를 완료하세요.
포드 또는 애플리케이션 매니페스트 내에 다음 환경 변수를 설정합니다.
NCCL_DEBUG=INFO NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p
이러한 환경 변수에 대한 자세한 내용은 NCCL 디버깅 로그 수집을 참고하세요.
로그 데이터를 생성하려면 NCCL 테스트를 실행합니다. 이 테스트를 실행하는 방법은 사용하는 클러스터 유형에 따라 달라집니다. GKE 클러스터의 경우 Topology Aware Scheduling(TAS)을 사용하여 NCCL 테스트를 배포하고 실행할 수 있습니다. NCCL 테스트를 실행하면 NCCL이 참여하는 모든 노드에서 자동으로 로그를 생성합니다.
모든 노드에서 로그를 수집합니다. 로그에 다음 정보가 포함되어 있는지 확인하여 모든 노드에서 NCCL 로그를 수집했는지 확인합니다.
- 워크로드에 포함된 모든 VM의 호스트 이름입니다.
- VM의 모든 관련 프로세스의 PID입니다.
- 각 VM에서 워크로드에 사용되는 모든 GPU의 순위입니다.
로그 파일이 어디에 있는지 잘 모르겠다면 다음 예시를 참고하세요. 이 예에서는
NCCL_DEBUG_FILE
변수가/tmp/nccl_log.%h.%p
로 설정된 경우 NCCL에서 로그 파일을 생성하는 위치를 보여줍니다.a3plus-vm-1
및a3plus-vm-2
이라는 VM이 두 개 있고 각 VM은 워크로드 컨테이너 내에서 8개의 프로세스를 실행합니다. 이 시나리오에서 NCCL은 각 VM의 워크로드 컨테이너 내/tmp
디렉터리 아래에 다음 로그 파일을 만듭니다.a3plus-vm-1
:nccl_log.a3plus-vm-1.PID
라는 로그 파일 8개(여기서PID
는 프로세스 ID임)a3plus-vm-2
:nccl_log.a3plus-vm-2.PID
라는 이름의 로그 파일 8개
로그를 검토하세요. NCCL 로그 항목의 형식은 다음과 같습니다.
HOSTNAME:PID:TID [RANK] NCCL_MESSAGE
이러한 로그 항목에는 다음 값이 포함됩니다.
HOSTNAME
: VM의 호스트 이름. 이 값은 NCCL이 로그 항목을 생성할 때 사용된 VM을 식별합니다.PID
: PID. 이 값은 로그 항목을 생성한 프로세스를 식별합니다.TID
: 스레드 ID 이 값은 NCCL이 로그 항목을 생성할 때 프로세스 내에서 사용된 스레드를 식별합니다.RANK
: 로컬 순위 ID. 이 값은 NCCL이 로그 항목을 생성할 때 사용된 GPU를 식별합니다. 순위는 0~N으로 번호가 지정되며, 여기서 N은 프로세스에 참여하는 총 GPU 수입니다. 예를 들어 워크로드가 VM당 GPU 8개로 실행되는 경우 각 VM에는 서로 다른 순위 값 (0~7)이 8개 있어야 합니다.NCCL_MESSAGE
: 이벤트에 관한 자세한 정보를 제공하고 NCCL이 로그를 생성한 타임스탬프를 포함하는 설명 메시지
예를 들면 다음과 같습니다.
gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.
이 예시에는 다음 값이 있습니다.
gke-a3plus-mega-np-2-aa33fe53-7wvq
: 호스트 이름1581
: 프로세스 ID1634
: 스레드 ID1
: 로컬 순위 IDNCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.
: 발생한 상황을 설명하는 메시지
지원 케이스를 여는 경우 수집한 로그와 NCCL 테스트 출력을 zip 파일로 패키징합니다. Cloud Customer Care에 지원 케이스를 제출할 때 ZIP 파일을 포함합니다.
NCCL 디버깅 로그 수집을 중지하려면 1단계에서 추가한 변수를 삭제합니다.
다음 단계
문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.
- Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
- StackOverflow에서 질문하고
google-kubernetes-engine
태그를 사용하여 유사한 문제를 검색해 커뮤니티의 지원을 받습니다.#kubernetes-engine
Slack 채널에 가입하여 더 많은 커뮤니티 지원을 받을 수도 있습니다. - 공개 Issue Tracker를 사용하여 버그나 기능 요청을 엽니다.