AI 최적화 GKE 클러스터 관리

이 페이지에서는 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 시간을 제공하여 특정 날짜 이후에 유지보수가 예약된 노드에만 포드를 예약하도록 GKE에 지시할 수 있습니다.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

AI 워크로드의 GKE 클러스터 업그레이드 관리

AI 워크로드는 중단에 민감합니다.

GKE 클러스터 수명 주기 동안 AI 워크로드는 기본 컴퓨팅 인스턴스와 GKE 클러스터 자체의 중단에 대비해야 합니다.

클러스터를 출시 채널에 등록해 두는 것이 좋습니다. GKE 클러스터는 기본적으로 일반 출시 채널에 등록됩니다. 출시 채널의 이점에 대한 자세한 내용은 출시 채널에 등록된 클러스터와 등록되지 않은 클러스터 비교 를 참고하세요.

출시 채널을 사용하면 추가 유지보수 제외 범위를 비롯한 더 많은 기능에 액세스할 수 있습니다. AI 워크로드에는 '마이너 또는 노드 업그레이드 없음' 범위를 사용하는 것이 좋습니다.

GKE를 통해 장애가 있는 호스트 신고

이 섹션에서는 GKE를 통해 예약 바인딩 프로비저닝 모델을 사용하여 프로비저닝된 컴퓨팅 인스턴스가 있는 장애가 있는 호스트를 신고하는 방법을 설명합니다. flex-start 프로비저닝 모델 (미리 보기)을 사용하여 프로비저닝된 노드의 장애가 있는 호스트를 신고하려면 계정팀에 문의하세요.

_호스트_는 GKE 노드를 호스팅하는 컴퓨팅 인스턴스를 실행하는 데이터 센터의 단일 물리적 서버 머신입니다. 영향을 받는 GKE 노드에 fault-behavior 노드 라벨을 적용하여 장애가 있는 호스트를 신고할 수 있습니다. 특정 GKE 노드에 노드 라벨을 적용하면 GKE는 다음 단계를 실행합니다.

  1. 노드에서 워크로드를 정상적으로 제거합니다.
  2. 새로운 포드가 노드에서 예약되지 않도록 합니다.
  3. 컴퓨팅 인스턴스에서 API를 호출하여 호스트를 장애가 있는 것으로 표시합니다.
  4. 정상 호스트 머신에서 컴퓨팅 인스턴스가 다시 시작될 때까지 기다립니다. 모든 용량 예약 작동 모드를 사용하는 예약의 경우 Compute Engine은 복구 작업이 완료된 후 동일한 노드에서 컴퓨팅 인스턴스를 다시 시작합니다.
  5. 노드에서 taint 및 fault-behavior 라벨을 삭제합니다.

그러면 노드가 다시 워크로드를 제공할 준비가 됩니다.

요구사항

장애가 있는 호스트를 신고하려면 GKE 노드가 다음 요구사항을 충족해야 합니다.

장애가 있는 호스트 신고

장애가 있는 호스트를 신고하려면 다음 단계를 따르세요.

  1. GKE 관측 도구, 자체 모니터링 도구 또는 로그를 사용하여 성능 문제가 발생하는 GKE 노드를 식별합니다. NODE_NAME을 저장합니다.

  2. 다음 명령어를 사용하여 노드를 장애가 있는 것으로 신고합니다. 이유를 제공할 수 있으며 이후 버전에서는 설명을 제공할 수 있습니다.

      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에 문의하여 장애 세부정보를 제공하세요.
노드의 장애가 있는 호스트를 신고한 후 노드가 다시 시작되는 시간은 노드가 사용하는 예약에 지정된 예약 작동 모드에 따라 달라집니다. 예약의 예약 작동 모드를 확인하려면 예약에서 reservationOperationalMode 필드를 확인하세요. 다음 표에는 사용 가능한 두 가지 예약 작동 모드인 모든 용량 모드 와 관리형 모드 의 장애가 있는 호스트 프로세스가 요약되어 있습니다.
모든 용량 모드 (ALL_CAPACITY) 관리형 모드 (HIGHLY_AVAILABLE_CAPACITY)
지원되는 머신 유형 A4X Max 및 A4X A4, A3 Ultra, A3 Mega, A3 High
장애가 있는 호스트 신고 API 비율 제한 비율 제한이 적용되지 않습니다. API 호출이 비율 제한될 수 있습니다.
장애가 있는 호스트 신고 프로세스

모든 용량 모드에서 실행되는 노드의 장애가 있는 호스트를 신고하면 다음이 발생합니다.

  1. 포드 제거: 라벨이 장애가 있는 노드에 적용되면 GKE 새 포드 예약을 차단하기 위해 노드를 taint합니다. 또한 GKE는 노드에서 실행 중인 포드를 정상적으로 제거하기 시작합니다. GKE respects the 포드 중단 예산 (PDB)과 spec.terminationGracePeriodSeconds 필드를 준수합니다. 자세한 내용은 GKE에서 워크로드를 정상적으로 종료하도록 구성을 참고하세요.
  2. 장애가 있는 호스트 신고 및 복구: GKE는 Compute Engine API를 호출하여 장애가 있는 호스트를 자동으로 신고하고 복구합니다. 이로 인해 장애가 있는 호스트를 신고하는 데 일반적으로 10~12분이 걸리고 호스트를 복구하는 데 3~14일 또는 때로는 더 오래 걸리는 일련의 작업이 발생합니다.

  3. 인스턴스 다시 시작: 호스트 복구 작업이 완료된 후 (일반적으로 3~14일) 다음 중 하나가 발생합니다.

    • 인스턴스가 REPAIRING 상태이고 복구가 완료될 때 리소스를 사용할 수 있는 경우 Compute Engine은 복구된 호스트에서 인스턴스를 자동으로 다시 시작합니다.
    • 그렇지 않고 복구가 완료될 때 인스턴스가 TERMINATED 상태이거나 리소스를 사용할 수 없는 경우 인스턴스 상태가 TERMINATED로 유지되거나 변경됩니다. 인스턴스를 실행하려면 수동으로 다시 시작해야 합니다. 하지만 인스턴스를 다시 시작할 때 리소스를 사용할 수 없는 경우 인스턴스 다시 시작이 실패할 수 있습니다. 예를 들어 다른 인스턴스가 이미 복구된 호스트를 사용하고 있는 경우에 발생할 수 있습니다.

관리형 모드에서 실행되는 노드의 장애가 있는 호스트를 신고하면 다음이 발생합니다.

  1. 포드 제거: 라벨이 장애가 있는 노드에 적용되면 GKE 새 포드 예약을 차단하기 위해 노드를 taint합니다. 또한 GKE는 노드에서 실행 중인 포드를 정상적으로 제거하기 시작합니다. GKE는 포드 중단 예산 (PDB)과 spec.terminationGracePeriodSeconds 필드를 준수합니다. 포드 매니페스트의 자세한 내용은 GKE에서 워크로드를 정상적으로 종료하도록 구성을 참고하세요.
  2. 장애가 있는 호스트 신고 및 복구 시작: GKE는 Compute Engine API를 호출하여 장애가 있는 호스트를 자동으로 신고하고 복구합니다. 이로 인해 장애가 있는 호스트를 신고하는 데 일반적으로 10~12분이 걸리고 호스트를 복구하는 데 3~14일 또는 때로는 더 오래 걸리는 일련의 작업이 발생합니다.

  3. 인스턴스 마이그레이션 및 다시 시작: 호스트 복구 작업이 시작 된 후(일반적으로 10~12분) Compute Engine은 예약된 용량에서 신고된 장애가 있는 호스트를 대체하기 위해 호스트를 하나 더 예약하려고 시도합니다. Compute Engine 정상 호스트를 찾으면(장애가 있는 호스트를 성공적으로 대체하거나 예약된 용량에서 일치하는 정상 호스트를 찾으면) Compute Engine 인스턴스를 해당 호스트로 마이그레이션합니다. 그런 다음 다음 중 하나를 통해 인스턴스를 다시 시작합니다.

    • 인스턴스가 REPAIRING 상태이고 복구가 완료되기 전이나 완료될 때 리소스를 사용할 수 있는 경우 Compute Engine은 정상 호스트에서 인스턴스를 자동으로 다시 시작합니다.
    • 그렇지 않고 복구가 완료되기 전이나 완료될 때 인스턴스가 TERMINATED 상태이거나 리소스를 사용할 수 없는 경우 인스턴스 상태가 TERMINATED로 유지되거나 변경됩니다. 인스턴스를 실행하려면 수동으로 다시 시작해야 합니다. 하지만 인스턴스를 다시 시작할 때 리소스를 사용할 수 없는 경우 인스턴스 다시 시작이 실패할 수 있습니다. 예를 들어 다른 인스턴스가 이미 복구된 호스트를 사용하고 있는 경우에 발생할 수 있습니다.

작업 진행 상황 모니터링

GKE 노드에서 cloud.google.com/report-and-replace-status 노드 라벨을 사용하여 GKE 작업의 진행 상황을 모니터링할 수 있습니다. 이 라벨에는 다음 값 중 하나가 있습니다.

  • PodsEvicted: GKE가 영향을 받는 노드에서 포드 제거를 완료했습니다.
  • OperationRUNNING: 장애가 있는 호스트를 신고하는 작업이 실행 중입니다.
  • OperationDONE: 기본 호스트가 장애가 있는 것으로 신고되었으며 GKE 노드를 새 호스트로 이동할 준비가 되었습니다.
  • OperationFAILED: 할당량 한도 또는 기타 인프라 문제로 인해 컴퓨팅 인스턴스의 API가 실패했습니다. 오류를 이해하려면 장애가 있는 호스트 신고 API 오류 문제 해결을 참고하세요. 복구 방법을 알아보려면 신고 및 교체 실패 처리를 참고하세요.
  • Error: 요청이 이전 섹션에 설명된 요구사항 중 하나를 충족하지 않아 API 호출이 실패했습니다.

cloud.google.com/report-and-replace-operation 노드 라벨 을 확인하여 Compute Engine 작업 ID를 확인하고 작업 상태를 모니터링할 수도 있습니다.

다음 명령어를 사용하여 이러한 두 노드 라벨을 모두 볼 수 있습니다.

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,cloud.google.com/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:NoSchedule taint를 자동으로 삭제합니다.

      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-

다음 단계