AI 최적화 GKE 클러스터 관리

이 페이지에서는 A4X Max, A4X, A4, A3 Ultra, A3 Mega, A3 High (GPU 8개) 머신의 AI 최적화 Google Kubernetes Engine (GKE) 클러스터를 관리하는 방법을 보여줍니다. 여기에는 GKE 클러스터 및 AI 워크로드와 관련된 다음 일반적인 이벤트가 포함됩니다.

  • 호스트 유지보수
  • 클러스터 업그레이드
  • 오작동하는 호스트 신고

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

특정 날짜 이후에 유지보수가 예정된 노드에 포드 예약

다음과 같이 유닉스 에포크 시간을 제공하여 특정 날짜 이후에 유지보수가 예약된 노드에만 포드를 예약하도록 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를 통해 예약 바운드 프로비저닝 모델을 사용하여 프로비저닝된 컴퓨팅 인스턴스가 있는 결함이 있는 호스트를 보고하는 방법을 설명합니다. 유연한 시작 프로비저닝 모델 (미리보기)을 사용하여 프로비저닝된 노드의 결함이 있는 호스트를 신고하려면 계정팀에 문의하세요.

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

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

이후 노드는 워크로드를 다시 제공할 준비가 됩니다.

요구사항

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

  • GKE 패치 버전 1.32.3-gke.1057001 이상을 실행해야 합니다.
  • 다음 GPU 머신 유형 중 하나를 실행해야 합니다. A4X Max, A4X, A4, A3 Ultra, A3 Mega, A3 High (8 GPU)
  • 예약에 바인딩된 컴퓨팅 인스턴스에서 GKE 노드를 실행해야 합니다.
  • GKE 노드는 RUNNING 상태여야 합니다. 컴퓨팅 인스턴스를 삭제한 후 장애가 있는 호스트를 신고하려고 하면 오류 메시지가 반환되고 호스트 머신이 장애가 있는 것으로 표시되지 않습니다.
  • 블록의 상태 평가에 따라 예약당 월별 이 API 호출 수가 제한될 수 있습니다. 예약에서 모든 용량 예약 작동 모드를 사용하는 경우 비율 제한이 적용되지 않습니다.

오작동하는 호스트 신고

오작동하는 호스트를 신고하려면 다음 단계를 따르세요.

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

  2. 노드를 결함이 있는 것으로 신고합니다.

      kubectl label nodes NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON
    

    다음을 바꿉니다.

    • NODE_NAME: 결함이 있는 노드의 이름입니다.
    • FAULT_REASON: 다음 값 중 하나 이상을 사용하여 적절한 오류 이유
      • PERFORMANCE: 컴퓨팅 인스턴스의 GPU가 클러스터의 다른 GPU보다 느리게 실행되고 로그에 XID 오류가 표시되지 않으며 무음 데이터 손상과 같은 다른 일반적인 실패 패턴이 감지되지 않는 경우 이 값을 사용합니다.
      • SDC: 데이터 손상이 표시되지만 시스템 비정상 종료가 없는 경우 드러나지 않은 데이터 손상에 이 값을 사용합니다. 이러한 데이터 손상은 CPU 결함, use-after-free 또는 메모리 스톰핑과 같은 소프트웨어 버그, 커널 문제 또는 기타 결함으로 인해 발생할 수 있습니다. 이 용어는 하드웨어로 인해 발생하는 결함을 지칭하는 데 가장 자주 사용됩니다.
      • XID: 컴퓨팅 인스턴스의 XID로 복구 불가 GPU 오류를 식별한 경우 이 값을 사용합니다.
      • unspecified: 컴퓨팅 인스턴스에서 문제를 일으키는 동작을 잘 모르는 경우 이 값을 사용하세요. 이 값이 기본값입니다. 하지만 해당하는 경우 다른 값 중 하나를 지정하는 것이 좋습니다.
노드의 결함이 있는 호스트를 신고한 후 노드가 다시 시작되는 시간은 노드가 사용하는 예약에 지정된 예약 작동 모드에 따라 달라집니다. 예약의 예약 작동 모드를 확인하려면 예약에서 reservationOperationalMode 필드를 확인하세요. 다음 표에는 사용 가능한 두 가지 예약 작동 모드(모든 용량 모드관리 모드)의 결함이 있는 호스트 프로세스가 요약되어 있습니다.
모든 용량 모드 (ALL_CAPACITY) 관리 모드 (HIGHLY_AVAILABLE_CAPACITY)
지원되는 머신 유형 A4X Max 및 A4X A4, A3 Ultra, A3 Mega, A3 High
결함이 있는 호스트 신고 API 비율 제한 비율 제한이 적용되지 않습니다. API 호출은 비율 제한될 수 있습니다.
오작동하는 호스트 신고 절차

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

  1. 포드 제거: 라벨이 결함이 있는 노드에 적용되면 GKE는 새 포드 예약이 차단되도록 노드를 taint합니다. 또한 GKE는 노드에서 실행 중인 포드를 단계적으로 제거하기 시작합니다. GKE는 포드 중단 예산 (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 노드를 새 호스트로 이동할 준비가 되었습니다.
  • 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에서 노드 taint를 삭제하고 cloud.google.com/fault-behavior 노드 라벨을 삭제합니다.

'장애가 있는 호스트 신고' 작업의 자세한 상태를 추적하는 방법을 알아보려면 장애가 있는 호스트 신고 작업 검토하기를 참고하세요.

비율 제한과 같은 일시적인 오류에 대해 작업을 다시 시도하려면 cloud.google.com/fault-behavior 라벨을 노드에 다시 적용하세요.

다음 단계