이 페이지는 Cloud Translation API를 통해 번역되었습니다.

GPU 및 TPU의 GKE 노드 중단 관리

Autopilot Standard

장기 실행 GKE 클러스터의 수명 주기 동안Google Cloud 에서 발생하는 인프라 중단으로 인해 주기적으로 워크로드가 중단됩니다. 이러한 자동 이벤트는 예약 결정(선점 이벤트), 컨트롤 플레인 또는 GKE 노드 자동 업그레이드(유지보수 이벤트)가 포함된 노드 업데이트 또는 감지된 문제 해결(종료 이벤트)에 대응하기 위해 발생할 수 있습니다.

이 페이지에서는 GKE에서 노드 중단이 의미하는 바를 이해하고, 유지보수 알림을 모니터링하고, GPU 및 TPU가 연결된 GKE 노드에서 서비스 중단의 영향을 최소화하는 방법을 설명합니다.

이 문서는 기본 기술 인프라의 수명 주기를 관리하는 플랫폼 관리자 및 운영자를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.

GKE에서 인프라 중단은 무엇을 의미하나요?

GKE 클러스터는 GKE 노드 수명 주기를 관리합니다. 이러한 노드는 Compute Engine VM에 프로비저닝되며, 주기적으로 다음과 같은 중단이 발생합니다.

감지된 문제 해결(TerminationEvent): 이러한 이벤트는 Google Cloud 에서 문제를 감지하고 클러스터 인프라를 중단하기 때문에 발생합니다. TerminationEvent 이벤트는 단계적 종료를 지원하지 않습니다. TerminationEvent 이벤트는 다음 문제로 인해 트리거됩니다.
- 자동 복구는 GKE에서 상태 점검 실패가 반복된 후 노드를 복구할 때 발생합니다.
- HostError는 물리적 머신의 하드웨어 또는 소프트웨어 오류로 인해 VM이 중지될 때 발생합니다.
참고: 기본 Compute Engine의 유지보수 이벤트는 자동 유지보수 이벤트로 간주됩니다. 이러한 이벤트는 GKE 유지보수 정책과 제외를 우회합니다.
유지보수 또는 업그레이드 이벤트(MaintenanceEvent): 이러한 이벤트는 Google Cloud 에서 유지보수를 실행하기 위해 VM을 중단해야 하는 경우에 발생합니다. MaintenanceEvent 이벤트는 다음 유지보수 태스크에 의해 트리거됩니다.
- 유지보수 이벤트는 Google Cloud 에서 기본 호스트를 업그레이드할 때 발생합니다.
- 노드 업데이트(노드 자동 업그레이드 포함)는 GKE가 노드에서 실행되는 Kubernetes 버전을 업데이트할 때 발생합니다.
클러스터 수명 주기 동안 사용자와 GKE가 변경사항을 관리하는 방법에 대한 자세한 내용은 변경사항 유형을 참조하세요.
예약 결정에 대한 응답(PreemptionEvent):Google Cloud 에서 우선순위가 높은 리소스에 용량을 제공하기 위해 VM을 선점해야 할 때 발생합니다. PreemptionEvent 이벤트는 다음 중 하나일 수 있습니다.
- 제거: 우선순위가 높은 VM을 수용하기 위해 선점형 또는 스팟 인프라가 선점될 때 발생합니다.
- 디스크 조각 모음: GKE가 더 큰 TPU 슬라이스를 수용하기 위해 더 작은 TPU 슬라이스를 선점할 때 발생합니다. 디스크 조각 모음은 TPU 슬라이스에서만 발생합니다.

장기 실행 GKE 클러스터의 수명 주기 동안 노드에서 학습 또는 서빙 워크로드 주기적인 중단이 발생할 수 있습니다. 이러한 중단이 AI/ML 워크로드를 실행하는 GKE 노드에 영향을 미치는 경우 GKE에서 실행 중인 워크로드와 기본 노드 모두 다시 시작해야 합니다.

GPU 및 TPU에서 중단 관리가 필요한 이유

일부 예외를 제외하고 대부분의 Compute Engine VM에는 라이브 마이그레이션으로 설정된 호스트 유지보수 정책이 있습니다. 즉, 실행 중인 워크로드가 일반적으로 거의 또는 전혀 중단되지 않습니다. 하지만 GPU 및 TPU가 연결된 VM을 포함하여 특정 클래스의 VM에서는 라이브 마이그레이션을 지원하지 않습니다. 호스트 이벤트가 TPU 슬라이스 내 VM에서 발생하면 모든 유지보수 이벤트가 슬라이스 수준에서 조정되므로 전체 슬라이스가 중단된 후 다시 예약됩니다. 따라서 VM이 수백 개인 TPU 슬라이스를 만들면 이러한 모든 VM이 동일한 유지보수 이벤트 일정을 수신합니다.

호스트 이벤트가 발생하면 GKE에서 노드와 해당 포드를 종료합니다. 포드가 작업 또는 배포와 같은 더 큰 워크로드의 일부로 배포되면 GKE는 영향을 받는 노드에서 포드를 다시 시작합니다.

유지보수 이벤트에 적절하게 반응하도록 워크로드 구성을 처리하는 것은 사용자 또는 사용하는 프레임워크에 달려 있습니다. 예를 들어 AI 학습 작업 상태를 저장하여 데이터 손실을 줄일 수 있습니다.

AI/ML 워크로드의 중단을 관리하려면 다음을 수행하세요.

노드 및 노드 풀 중단 모니터링
유지보수 알림 모니터링
중단 영향 최소화

노드 중단 모니터링

다음 GKE 시스템 측정항목은 마지막 샘플 이후 GKE 노드의 중단 수를 보고합니다(측정항목은 60초마다 샘플링됨).

kubernetes.io/node/interruption_count

interruption_type(예: TerminationEvent, MaintenanceEvent, PreemptionEvent) 및 interruption_reason(예: HostError, Eviction, AutoRepair) 필드는 노드가 중단된 이유를 제공하는 데 도움이 될 수 있습니다.

프로젝트의 클러스터에 있는 TPU 노드의 중단 및 원인을 분류하려면 다음 PromQL 쿼리를 사용하세요.

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

호스트 유지보수 이벤트만 표시하려면 interruption_reason에 대한 HW/SW Maintenance 값을 필터링하도록 쿼리를 업데이트합니다. 다음 PromQL 쿼리를 사용합니다.

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

노드 풀별로 집계된 중단 수를 확인하려면 다음 PromQL 쿼리를 사용하세요.

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

유지보수 알림 모니터링

노드와 기본 VM에 중단이 발생하는 호스트 이벤트가 예약된 경우와 이러한 이벤트가 활성화된 경우 Compute Engine에서 알림을 발행합니다. 알림에는 예정된 시작 시간, 이벤트 유형, 기타 세부정보가 포함됩니다.

GKE 버전 1.31.1-gke.2008000 이상에서는 이 섹션에 설명된 이벤트를 비롯하여 예정된 유지보수 이벤트를 모니터링할 수 있습니다.

예정된 유지보수가 예약되었으나 활성화되지 않음

연결된 GPU 또는 TPU가 있는 VM에 예정된 유지보수 이벤트가 발생하기 전에 Compute Engine은 모든 VM에 알림을 푸시합니다. 이러한 알림은 유지보수 기간의 시작을 보고합니다. VM에서 예정된 유지보수가 예약되었지만 활성 상태가 아니면 GKE는 노드 라벨에 scheduled-maintenance-time을 추가합니다.

노드 수준에서 이러한 알림을 쿼리하려면 다음 명령어를 실행합니다.

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

출력은 다음과 비슷합니다.

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

SCHEDULED-MAINTENANCE-TIME 열은 초를 나타내며 유닉스 시간 형식으로 표시됩니다.

노드 메타데이터 수준에서 이러한 알림을 쿼리하려면 인스턴스에서 유지보수 이벤트 알림을 확인하세요.

고급 유지보수를 지원하는 가속기 최적화 머신 계열의 경우 예약되고 시작된 유지보수 이벤트에 관한 정보를 제공하는 upcoming-maintenance 엔드포인트에 액세스할 수 있습니다.

중단 영향 최소화

Compute Engine은 예정된 유지보수 이벤트에 대한 알림을 보내고 유지보수 기간을 예약합니다. 알림 시간과 유지보수 기간 시작 시간 사이에 다음 중 하나를 결정할 수 있습니다.

수동으로 호스트 유지보수 이벤트 시작
Compute Engine이 일정에 따라 유지보수 이벤트 시작

수동으로 호스트 유지보수 이벤트 시작

Compute Engine에서 예약된 유지보수 이벤트에 관한 알림을 보내면 활동이 줄어드는 기간과 같이 운영 일정에 맞는 시간에 유지보수를 수동으로 시작할 수 있습니다.

노드 풀의 노드에서 노드 라벨 cloud.google.com/perform-maintenance을 true로 설정합니다. 예를 들면 다음과 같습니다.

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

사용자가 유지보수 이벤트를 시작하면 GKE는 다음 작업을 실행합니다.

노드를 taint합니다.
포드를 단계적으로 제거합니다.
예약된 시간을 기다리지 않고 유지보수 이벤트를 즉시 시작하도록 Compute Engine에 요청합니다.

Compute Engine이 일정에 따라 유지보수 이벤트 시작

호스트 유지보수 이벤트를 시작하지 않으면 Compute Engine에서 예약된 유지보수 이벤트를 자동으로 시작합니다. GKE 버전 1.33부터는 유지보수 기간이 시작될 때 노드가 taint되지 않고 포드가 제거되지 않습니다.

유지보수 이벤트가 시작되면 노드가 임박한 종료 전에 짧은 알림 시간과 함께 한 번 또는 여러 번 종료될 수 있습니다. 이 경우 GKE는 워크로드를 종료하고 포드를 정상적으로 제거하기 위해 최선을 다합니다.

예약된 유지보수 시작

예약된 유지보수가 시작되면 Compute Engine은 http://metadata.google.internal/computeMetadata/v1/instance/attributes/ 디렉터리의 메타데이터를 업데이트합니다. Compute Engine은 다음과 같이 메타데이터 라벨을 업데이트합니다.

maintenance-event를 TERMINATE_ON_HOST_MAINTENANCE로 설정합니다.
upcoming-maintenance에서 maintenance_status를 ONGOING으로 설정합니다.

GKE는 예약된 호스트 유지보수 이벤트를 수동으로 트리거하는지 아니면 GKE가 자동으로 진행하도록 하는지에 따라 처리합니다.

GKE에서 워크로드를 정상적으로 종료하도록 구성

이 섹션에서는 GKE에서 애플리케이션 수명 주기를 관리하고 워크로드 중단을 최소화하도록 구성합니다. 유예 기간을 구성하지 않으면 유예 기간은 기본적으로 30초로 설정됩니다.

GKE는 이러한 포드를 정상적으로 종료하고 개발자가 정의한 종료 작업(예: 학습 상태 저장)을 실행하기 위해 최선을 다합니다. GKE는 유예 기간이 시작될 때 SIGTERM 신호를 포드에 전송합니다. 유예 기간이 종료될 때까지 포드가 종료되지 않으면 GKE는 후속 SIGKILL 신호를 포드의 컨테이너에서 계속 실행 중인 모든 프로세스에 전송합니다.

정상 종료 기간을 구성하려면 포드 매니페스트의 spec.terminationGracePeriodSeconds 필드에서 종료 유예 기간(초)을 설정합니다. 예를 들어 10분의 알림 시간을 가져오려면 포드 매니페스트에서 spec.terminationGracePeriodSeconds 필드를 다음과 같이 600초로 설정합니다.

    spec:
      terminationGracePeriodSeconds: 600

진행 중인 작업이 알림 기간 내에 완료될 수 있도록 종료 유예 기간을 충분히 길게 설정하는 것이 좋습니다. 워크로드에서 MaxText, Pax, 또는 JAX(Orbax 사용)와 같은 ML 프레임워크를 사용하면 종료 SIGTERM 신호를 캡처하고 체크포인트 프로세스를 시작할 수 있습니다. 자세한 내용은 TPU 자동 체크포인트를 참조하세요.

정상 종료 절차

수동으로 시작된 유지보수 이벤트가 시작되면 Compute Engine은 maintenance-event 메타데이터 키를 업데이트하여 머신 종료가 임박했음을 알립니다. GKE가 단계적 종료를 시작합니다.

다음 워크플로에서는 노드 종료가 임박한 경우 GKE에서 정상 노드 종료를 실행하는 방법을 보여줍니다.

60초 이내에 다음이 발생합니다.
1. 시스템 구성요소는 cloud.google.com/active-node-maintenance 노드 라벨을 ONGOING으로 설정하여 워크로드가 중지되고 있음을 나타냅니다.
2. GKE는 새 포드가 노드에서 예약되지 않도록 노드 taint를 적용합니다. taint에 cloud.google.com/impending-node-termination:NoSchedule 키가 있습니다. 발생하는 알려진 종료로 인해 이 taint를 허용하도록 워크로드를 수정하지 않는 것이 좋습니다.
maintenance-handler 구성요소는 먼저 워크로드 포드를 제거한 다음 시스템 포드(예: kube-system)를 제거하여 포드를 제거하기 시작합니다.
GKE는 노드에서 실행 중인 워크로드 포드에 SIGTERM 종료 신호를 전송하여 종료가 임박했음을 알립니다. 포드는 이 알림을 사용하여 진행 중인 모든 태스크를 마칠 수 있습니다. GKE는 이러한 포드가 정상적으로 종료되도록 최선을 다합니다.
제거가 완료되면 GKE는 cloud.google.com/active-node-maintenance 라벨의 값을 terminating으로 업데이트하여 노드를 종료할 준비가 되었음을 나타냅니다.

그런 다음 노드 종료가 발생하고 교체 노드가 할당됩니다. 프로세스가 완료되면 GKE에서 라벨과 taint를 삭제합니다. GPU 또는 TPU를 사용하는 워크로드의 종료 기간을 늘리려면 호스트 유지보수 이벤트 수동 시작 섹션의 단계를 완료합니다.

정상적인 활성 종료 진행 상황 모니터링

다음과 같은 정상 종료 이벤트를 기준으로 GKE 로그를 필터링할 수 있습니다.

VM이 Compute Engine 호스트 유지보수 이벤트와 같이 노드 종료 임박으로 인한 중단을 감지하면 GKE는 워크로드가 중지될 때 cloud.google.com/active-node-maintenance를 ONGOING으로, 워크로드가 완료되고 노드가 종료될 준비가 되면 terminating으로 설정합니다.
새 워크로드 예약을 제한하는 경우 GKE는 cloud.google.com/impending-node-termination:NoSchedule taint를 적용합니다.

기회적 유지보수로 실행 중인 워크로드의 중단 최소화

GKE에서 GPU 또는 TPU가 있는 노드가 유휴 상태임을 감지할 때 유지보수를 자동으로 트리거하여 실행 중인 워크로드의 중단을 최소화할 수 있습니다. 이 기능을 사용 설정하려면 새 노드 풀을 만드세요. 기존 노드 풀에서는 기회적 유지보수를 사용 설정할 수 없습니다.

기회적 유지보수로 새 노드 풀 만들기

다음 명령어는 기회적 유지보수가 사용 설정된 노드 풀을 만드는 방법을 보여줍니다.

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

다음 값을 바꿉니다.

NODE_POOL_NAME: GKE 노드 풀의 이름입니다.
CLUSTER_NAME: GKE 클러스터의 이름
NODE_IDLE_TIME : 유지보수가 트리거되기 전에 노드가 유휴 상태로 유지될 수 있는 시간입니다 (즉, 액셀러레이터 사용 워크로드가 실행되지 않음). 값은 초 단위 기간을 나타내며, 소수점 아래 9자리까지 지정 가능하고 s 문자로 끝납니다(예: 80000s).
MIN_NODES : 노드 풀에서 사용할 수 있어야 하는 최소 노드 수입니다. 이 옵션은 실행 중인 노드 수가 이 값 아래로 떨어지는 경우 유지보수를 차단합니다(예: 10).
WINDOW : 기회적 유지보수를 실행할 수 있는 시간(초)입니다. 값이 s 문자로 끝납니다. 예를 들어 값이 14일(1209600s)이면 예정된 유지보수 날짜 2주 전에만 기회적 유지보수를 실행할 수 있습니다. 28일 또는 2419200s 값을 사용하면 예약된 유지보수 기간 중 언제든지 기회적 유지보수를 실행할 수 있습니다. Compute Engine 호스트 유지보수 기간은 GKE 클러스터 유지보수가 발생할 수 있는 시기를 결정하고 별도로 구성되는 GKE 유지보수 기간과 다릅니다.

기회성 유지보수를 위한 구성 예시

구체적인 사례를 살펴보겠습니다. 노드가 4개인 노드 풀이 있고 기회적 유지관리 구성이 --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3로 설정되어 있습니다. 이 시나리오에서는 다음이 발생합니다.

node1에 GPU 워크로드가 실행되고 있습니다. 이 노드는 유휴 상태가 아니므로 건너뜁니다.
node2이(가) 60초 동안 유휴 상태입니다. 이 노드는 충분한 시간 동안 유휴 상태가 아니므로 건너뜁니다.
node3이(가) 600초 동안 유휴 상태였습니다. 이 노드는 유휴 요구사항을 충족합니다.
node4이(가) 600초 동안 유휴 상태였습니다. 이 노드는 유휴 요구사항을 충족합니다.

node3와 node4 모두 유휴 요구사항을 충족합니다. 하지만 min-nodes 옵션의 값이 3으로 설정되어 있으므로 이러한 노드 중 하나만 기회적 유지보수를 트리거합니다.

기회적 유지보수가 적용된 노드의 구성 및 상태 확인

다음 명령어를 실행하여 노드에 대해 기회적 유지보수가 구성되었는지 확인합니다.

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

NODE_NAME을 확인하려는 노드의 이름으로 바꿉니다.

기회적 유지보수로 구성된 노드가 현재 유지보수 중인지 확인합니다.

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

노드가 기회적 유지보수에 의해 트리거되는 경우 maintenance-state 주석은 opportunistic-triggered을 true로 표시합니다.

제한사항

기회성 유지보수의 제한사항은 다음과 같습니다.

이 기능은 GPU 및 TPU 노드 풀에서만 사용할 수 있습니다.
클러스터 자동 확장 처리가 이미 유휴 노드를 축소하므로 기회적 유지보수는 클러스터 자동 확장과 호환되지 않습니다.
멀티 호스트 TPU 노드 풀의 경우 이러한 노드 풀이 원자적이므로 min-nodes-per-pool 설정 값이 0이어야 합니다.
지원되는 최소 GKE 버전은 1.33.3-gke.1118000입니다.
can_reschedule=TRUE 알림이 포함된 계획된 유지보수만 지원됩니다.
이 기능을 사용 중지하려면 해당 플래그 없이 노드 풀을 다시 만들어야 합니다. 또는 cloud.google.com/opportunistic-disable=true를 사용하여 특정 노드에서 기능을 수동으로 사용 중지할 수 있습니다.
드물지만 노드에서 유지보수가 완료되는 데 시간이 더 오래 걸릴 수 있습니다. 이 기능을 사용하는 고객은 한동안 사용 가능한 노드가 min-nodes-per-pool 설정 값까지 줄어들 수 있습니다.