이 페이지에서는 GKE 클러스터 및 AI 워크로드와 관련된 다음과 같은 일반적인 이벤트를 포함하여 A4X Max, A4X, A4, A3 Ultra, A3 Mega, A3 High(GPU 8개) 머신의 AI 최적화 Google Kubernetes Engine(GKE) 클러스터를 관리하는 방법을 보여줍니다.
- 호스트 유지보수
- 클러스터 업그레이드
- 오작동하는 호스트 신고
AI 워크로드의 호스트 유지보수 관리
GKE 노드는 AI 워크로드를 중단시킬 수 있는 호스트 이벤트가 주기적으로 발생하는 Compute Engine 인스턴스에서 실행됩니다. 호스트 이벤트는 기본Google Cloud 인프라에서 발생하므로 GKE 유지보수 기간 및 제외를 우회합니다. 대부분의 컴퓨팅 인스턴스에는 워크로드 중단을 최소화하는 라이브 마이그레이션으로 설정된 호스트 유지보수 정책이 있지만 GPU 및 TPU는 라이브 마이그레이션을 지원하지 않습니다. 이러한 호스트 이벤트가 AI 워크로드를 실행하는 GKE 노드에 영향을 미치는 경우 GKE는 노드와 노드에서 실행 중인 포드를 종료해야 합니다. 포드가 작업 또는 배포와 같은 더 큰 워크로드의 일부로 배포되면 GKE는 영향을 받는 노드에서 포드를 다시 시작하려고 시도합니다.
기본 컴퓨팅 인스턴스의 호스트 유지보수를 관리하는 방법에 대한 자세한 내용은 GPU 및 TPU에 대한 GKE 노드 중단 관리를 참조하세요.
호스트 유지보수 이벤트 모니터링
GKE 버전 1.31.1-gke.2008000 이상을 실행하는 클러스터의 경우 다음과 같은 방법으로 호스트 유지보수 이벤트의 예약된 시작 시간을 확인할 수 있습니다. 시작 시간은 모든 GPU 및 TPU의 해당 GKE 노드에 있는 Kubernetes 노드 라벨로 표시됩니다.
자세한 내용은 유지보수 알림 모니터링을 참조하세요.
이러한 노드 라벨을 사용하여 다음을 수행할 수 있습니다.
수동으로 호스트 유지보수 이벤트 시작
Compute Engine에서 예약된 유지보수 이벤트에 대한 알림을 보낸 후 일정에 맞춰 유지보수를 수동으로 시작할 수 있습니다. 예를 들어 활동이 줄어든 기간 동안 유지보수를 수행하도록 선택할 수 있습니다.
호스트 유지보수 이벤트를 수동으로 시작하지 않으면 Compute Engine에서 정기적으로 예약된 유지보수를 자동으로 완료합니다.
수동으로 호스트 유지보수 이벤트 시작 안내를 따릅니다. 또한 이 섹션을 계속 읽고 다음 사항을 알아보세요.
워크로드를 예약하는 동안 호스트 유지보수 정보 사용
GKE 노드 라벨을 통해 표시되는 유지보수 정보를 노드 어피니티 및 안티 어피니티와 함께 사용하여 워크로드 중단을 최소화할 수 있습니다.
이 정보를 사용하는 방법의 예시는 다음 섹션을 참고하세요.
향후 예약된 유지보수 이벤트가 없는 노드에 포드 예약
다음 스니펫과 같이 향후 예약된 유지보수 이벤트가 없는 노드에만 포드를 예약하도록 GKE에 지시할 수 있습니다.
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/scheduled-maintenance-time
operator: DoesNotExist
특정 날짜 이후에 유지보수가 예약된 노드에 포드 예약
유닉스 시간(Unix epoch time)을 제공하여 특정 날짜 이후에 유지보수가 예약된 노드에만 포드를 예약하도록 GKE에 지시할 수 있습니다.
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/scheduled-maintenance-time
operator: Gt
values:
- 1733296000
AI 워크로드의 GKE 클러스터 업그레이드 관리
AI 워크로드는 중단에 민감합니다.
GKE 클러스터의 수명 주기 동안 AI 워크로드는 기본 컴퓨팅 인스턴스와 GKE 클러스터 자체의 중단에 대비해야 합니다.
- 호스트 유지보수: 기본 컴퓨팅 인스턴스의 호스트 유지보수를 관리하려면 GPU 및 TPU에 대한 GKE 노드 중단 관리를 참조하세요. 이전 섹션에서도 설명되어 있습니다.
- 클러스터 업그레이드: 클러스터 업그레이드로 인한 중단을 관리하려면 다음 도구를 사용하면 됩니다.
클러스터를 출시 채널에 등록된 상태로 유지하는 것이 좋습니다. GKE 클러스터는 기본적으로 일반 출시 채널에 등록됩니다. 출시 채널의 이점에 대한 자세한 내용은 출시 채널에 등록된 클러스터와 등록되지 않은 클러스터 비교를 참조하세요.
출시 채널을 사용하면 추가 유지보수 제외 범위를 포함한 더 많은 기능에 액세스할 수 있습니다. AI 워크로드에는 '마이너 또는 노드 업그레이드 없음' 범위를 사용하는 것이 좋습니다.
GKE를 통해 장애가 있는 호스트 신고
이 섹션에서는 GKE를 통해 표준, flex-start 또는 예약 범위 프로비저닝 모델을 사용하여 프로비저닝된 컴퓨팅 인스턴스가 있는 결함이 있는 호스트를 보고하는 방법을 간략하게 설명합니다. 스팟 프로비저닝 모델을 사용하여 프로비저닝되었거나 일반 GPU를 사용하는 노드의 결함이 있는 호스트를 신고하려면 계정팀에 문의하세요.
노드에서 GPU 메모리 또는 Xid 오류가 발생하고 호스트를 장애가 있는 것으로 신고하기 전에 게스트 OS 재부팅(kubectl label
nodes <NODE_NAME> cloud.google.com/perform-reboot=true) 트리거와 같은 수동 복구 조치로 문제를 해결할 수 있는지 확인하려면 Xid 메시지 검토를 참조하세요.
호스트는 GKE 노드를 호스팅하는 컴퓨팅 인스턴스를 실행하는 데이터 센터의 단일 물리적 서버 머신입니다. 영향을 받는 GKE 노드에 fault-behavior 노드 라벨을 적용하여 결함이 있는 호스트를 신고할 수 있습니다. 특정 GKE 노드에 노드 라벨을 적용하면 GKE에서 다음 단계를 수행합니다.
- 노드에서 워크로드를 단계적으로 제거합니다.
- 새 포드가 노드에 예약되지 않도록 합니다.
- 컴퓨팅 인스턴스에서 API를 호출하여 호스트를 장애가 있는 것으로 표시합니다.
- 컴퓨팅 인스턴스가 정상 호스트 머신에서 다시 가동될 때까지 기다립니다. 모든 용량 예약 작동 모드를 사용하는 예약의 경우 Compute Engine은 복구 작업이 완료된 후 동일한 노드에서 컴퓨팅 인스턴스를 다시 가져옵니다.
- 노드에서 taint와
fault-behavior라벨을 삭제합니다.
이후 노드는 워크로드를 다시 제공할 준비가 됩니다.
요구사항
장애가 있는 호스트를 보고하려면 GKE 노드가 다음 요구사항을 충족해야 합니다.
- GKE 패치 버전 1.32.3-gke.1057001 이상을 실행해야 합니다.
- A4X Max, A4X, A4, A3 Ultra, A3 Mega, A3 High(GPU 8개) 중 하나의 GPU 머신 유형을 실행해야 합니다.
- 예약 바인딩된 컴퓨팅 인스턴스에서 GKE 노드를 실행해야 합니다.
- GKE 노드가
RUNNING상태여야 합니다. 컴퓨팅 인스턴스를 삭제한 후 장애가 있는 호스트를 신고하려고 하면 오류 메시지가 반환되고 호스트 머신이 장애가 있는 것으로 표시되지 않습니다. - 블록의 상태 평가에 따라 예약당 월별 이 API 호출 수에 비율 제한이 적용될 수 있습니다. 예약에서 모든 용량 예약 작동 모드를 사용하는 경우 비율 제한이 적용되지 않습니다.
오작동하는 호스트 신고
오작동하는 호스트를 신고하려면 다음 단계를 따르세요.
GKE 모니터링 가능성 도구, 자체 모니터링 도구 또는 로그를 사용하여 성능 문제가 발생하는 GKE 노드를 식별합니다.
NODE_NAME를 저장합니다.다음 명령어를 사용하여 노드를 결함이 있는 것으로 보고합니다. 이유를 제공할 수 있으며 이후 버전에서는 설명을 제공할 수 있습니다.
kubectl patch node NODE_NAME --type merge -p '{ "metadata": { "labels": { "cloud.google.com/fault-behavior": "FAULT_REASON" }, "annotations": { "cloud.google.com/fault-description": "FAULT_DESCRIPTION" } } }'다음과 같이 명령어를 수정합니다.
NODE_NAME을 결함이 있는 노드의 이름으로 바꿉니다.FAULT_REASON을 다음 값 중 하나 이상을 사용하여 적절한 오류 이유로 바꿉니다.PERFORMANCE: 컴퓨팅 인스턴스의 GPU가 클러스터의 다른 GPU보다 느리게 실행되고 로그에 XID 오류가 표시되지 않으며 자동 데이터 손상과 같은 다른 일반적인 오류 패턴이 감지되지 않는 경우 이 값을 사용합니다.SDC: 데이터 손상이 있지만 시스템 비정상 종료가 없는 경우 드러나지 않은 데이터 손상에 이 값을 사용합니다. 이러한 데이터 손상은 CPU 결함, use-after-free 또는 메모리 스톰핑과 같은 소프트웨어 버그, 커널 문제 또는 기타 결함으로 인해 발생할 수 있습니다. 대부분의 경우 이 용어는 하드웨어로 인한 결함을 지칭하는 데 사용됩니다.XID: 컴퓨팅 인스턴스의 XID를 사용하여 복구 불가 GPU 오류를 식별한 경우 이 값을 사용합니다.unspecified: 컴퓨팅 인스턴스에 문제를 일으키는 동작을 잘 모르는 경우 이 값을 사용합니다. 이 설정이 기본 설정입니다. 하지만 해당하는 경우 다른 값 중 하나를 지정하는 것이 좋습니다.
- GKE 클러스터의 컨트롤 플레인 버전에 따라
annotations블록을 조정합니다.- 1.35.6-gke.1017000 이상 또는 1.36.0-gke.3251000 이상: 주석 블록을 유지하고
FAULT_DESCRIPTION를 관찰된 오류의 텍스트 설명으로 바꿉니다. 여기에는 XID 오류 코드, 증상 또는 타임스탬프가 포함될 수 있습니다. 이 설명은 복구 진단을 지원하기 위해 Compute Engine으로 전달되며 작업이 완료되면 노드에서 자동으로 삭제됩니다. 예를 들면 다음과 같습니다.GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z - 이전 버전: 명령어에서
annotations블록 전체를 삭제합니다.fault-description필드는 이러한 버전에서 Compute Engine으로 전달되지 않으며 노드에서 자동으로 삭제되지 않습니다. 대신 계정팀 또는 Cloud Customer Care에 연락하여 오류 세부정보를 제공하세요.
- 1.35.6-gke.1017000 이상 또는 1.36.0-gke.3251000 이상: 주석 블록을 유지하고
reservationOperationalMode 필드를 확인합니다.
다음 표에는 사용 가능한 두 가지 예약 작동 모드인 모든 용량 모드와 관리형 모드의 결함이 있는 호스트 프로세스가 요약되어 있습니다.
모든 용량 모드(ALL_CAPACITY) |
관리 모드(HIGHLY_AVAILABLE_CAPACITY) |
|
|---|---|---|
| 지원되는 머신 유형 | A4X Max 및 A4X | A4, A3 Ultra, A3 Mega, A3 High(GPU 8개) |
| 결함이 있는 호스트 보고서 API 비율 제한 | 비율 제한은 적용되지 않습니다. | API 호출은 비율이 제한될 수 있습니다. |
| 장애가 있는 호스트 신고 프로세스 |
모든 용량 모드에서 실행되는 노드의 장애가 있는 호스트를 신고하면 다음이 발생합니다.
|
관리 모드에서 실행되는 노드의 장애가 있는 호스트를 신고하면 다음이 발생합니다.
|
작업 진행 상태 모니터링
GKE 노드에서 다음 값 중 하나를 갖는 cloud.google.com/report-and-replace-status 노드 라벨을 사용하여 GKE 작업 진행 상황을 모니터링할 수 있습니다.
PodsEvicted: GKE가 영향을 받는 노드에서 포드 제거를 완료했습니다.OperationRUNNING: 오류 호스트를 보고하는 작업이 실행 중입니다.OperationDONE: 기본 호스트가 잘못된 것으로 신고되었으며 GKE 노드를 새 호스트로 이동할 준비가 되었습니다.OperationFAILED: 할당량 한도 또는 기타 인프라 문제로 인해 컴퓨팅 인스턴스의 API가 실패했습니다. 오류를 이해하려면 결함이 있는 호스트 API 오류 보고 문제 해결을 참조하세요. 복구 방법을 알아보려면 보고 및 교체 실패 처리를 참조하세요.Error: 요청이 이전 섹션에 설명된 요구사항 중 하나를 충족하지 않아 API 호출이 실패했습니다.
node.gke.io/report-and-replace-operation 노드 라벨을 확인하여 Compute Engine 작업 ID를 확인하고 작업 상태를 모니터링할 수도 있습니다.
다음 명령어를 사용하여 두 노드 라벨을 모두 볼 수 있습니다.
kubectl get nodes NODE_NAME \
-L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation
API 오류가 발생하면 GKE는 cloud.google.com/report-and-replace-status 노드 라벨을 Error로 설정합니다. 작업 실패가 발생하면 GKE는 라벨을 OperationFAILED로 설정합니다.
두 경우 모두 GKE는 cloud.google.com/fault-behavior 노드 라벨을 삭제합니다. 또한 GKE 버전 1.35.6-gke.1256000 이상 또는 1.36.0-gke.4060000 이상에서 GKE는 노드에 cloud.google.com/report-and-replace-failed:NoSchedule taint를 적용합니다. 이 taint는 새 포드가 노드에 예약되지 않도록 하여 워크로드가 결함이 있을 수 있는 호스트가 있는 노드에 배치되지 않도록 합니다. 자세한 내용은 보고 및 교체 실패 처리를 참조하세요.
장애 호스트 신고 작업의 세부 상태를 추적하는 방법을 알아보려면 장애 호스트 신고 작업 검토를 참조하세요.
신고 및 교체 실패 처리
보고 및 교체 작업이 실패하면 GKE는 영향을 받는 노드에 cloud.google.com/report-and-replace-failed:NoSchedule taint를 적용합니다. 이 taint는 기본 호스트에 여전히 결함이 있을 수 있는 동안 새 워크로드가 예약되지 않도록 노드를 차단된 상태로 유지합니다.
실패 taint 확인
노드에 보고 및 교체 실패 taint가 있는지 확인하려면 다음 명령어를 실행합니다.
kubectl describe node NODE_NAME | grep "report-and-replace-failed"
보고 및 교체 실패에서 복구
보고 및 교체 실패에서 복구하려면 다음 중 하나를 수행합니다.
노드에
cloud.google.com/fault-behavior라벨을 다시 적용하여 작업을 다시 시도합니다. 재시도가 성공하면 GKE는cloud.google.com/report-and-replace-failed:NoScheduletaint를 자동으로 삭제합니다.kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON노드가 정상이라고 판단하거나 서비스로 반환하려면 수동으로 taint를 삭제합니다.
kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-
다음 단계
Topology Aware Scheduling으로 GKE 워크로드를 예약하는 방법 알아보기
NCCL/gIB를 사용하여 클러스터 네트워킹을 최적화하는 방법 알아보기
결함이 있는 호스트 API 오류 보고 문제를 해결하는 방법을 알아보세요.