GKE에서 호스트 유지보수를 수행하는 방법 이해

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

이 문서는 GKE에서 노드 중단이 의미하는 바를 이해하고 GKE 노드에서 서비스 중단의 영향을 최소화하는 데 도움이 됩니다.

유지보수 알림 및 이벤트 모니터링에 대한 자세한 내용은 유지보수 이벤트 모니터링을 참조하세요.

이 문서는 다음 머신 유형에 적용됩니다.

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

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

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

  • 감지된 문제 해결 (TerminationEvent): 이러한 이벤트는 에서 문제를 감지하고 클러스터 인프라를 중단하기 때문에 발생합니다. Google Cloud TerminationEvent 이벤트는 단계적 종료를 지원하지 않습니다. TerminationEvent 이벤트는 다음 문제로 인해 트리거됩니다.

    • 자동 복구는 GKE에서 상태 점검 실패가 반복된 후 노드를 복구할 때 발생합니다.
    • HostError 는 물리적 머신의 하드웨어 또는 소프트웨어 오류로 인해 VM이 중지될 때 발생합니다.

  • 유지보수 또는 업그레이드 이벤트 (MaintenanceEvent): 이러한 이벤트는 에서 Google Cloud 유지보수를 실행하기 위해 VM을 중단해야 하는 경우에 발생합니다. 이러한 이벤트는 다음 유지보수 작업에 의해 트리거됩니다.

    클러스터 수명 주기 동안 사용자와 GKE가 변경사항을 관리하는 방법에 대한 자세한 내용은 변경사항 유형을 참조하세요.

  • 예약 결정에 대한 응답 (PreemptionEvent): 이러한 이벤트는 에서 Google Cloud 우선순위가 높은 리소스에 용량을 제공하기 위해 VM을 선점해야 할 때 발생합니다. PreemptionEvent 이벤트는 다음 중 하나일 수 있습니다.

    • 제거: 우선순위가 높은 VM을 수용하기 위해 선점형 또는 스팟 인프라가 선점될 때 발생합니다.
    • 디스크 조각 모음: GKE가 더 큰 TPU 슬라이스를 수용하기 위해 더 작은 TPU 슬라이스를 선점할 때 발생합니다. 디스크 조각 모음은 TPU 슬라이스에서만 발생합니다.

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

라이브 마이그레이션을 지원하지 않는 노드에 중단 관리가 필요한 이유

일부 예외를 제외하고 대부분의 Compute Engine VM에는 호스트 유지보수 정책이 라이브 마이그/3}레이션으로 설정되어 있습니다. 즉, 실행 중인 워크로드가 일반적으로 거의 또는 전혀 중단되지 않습니다. 하지만 특정 클래스의 VM에서는 라이브 마이그레이션을 지원하지 않습니다. 여기에는 연결된 GPU 및 TPU가 있는 VM, SSD가 18TiB를 초과하는 Z3 머신 유형, H4D 머신 유형, c4a-highmem-96-metal 머신 유형이 포함됩니다. 예를 들어 호스트 이벤트가 TPU 슬라이스 내의 VM에서 발생하면 모든 유지보수 이벤트가 슬라이스 수준에서 조정되므로 전체 슬라이스가 중단된 후 일정이 변경됩니다. 따라서 VM이 수백 개 있는 TPU 슬라이스를 만들면 이러한 모든 VM에 동일한 유지보수 이벤트 일정이 적용됩니다.

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

유지보수 이벤트 관리

이 문서의 나머지 부분에서는 MaintenanceEvent 중단을 관리하는 방법을 설명합니다.

호스트 유지보수 이벤트 중에 노드 중단을 관리하는 것은 3단계 워크플로를 따릅니다.

  1. 예약된 호스트 유지보수 감지: GKE 노드 라벨, 메타데이터 엔드포인트 또는 로그를 사용합니다.
  2. 감지된 유지보수에 대한 조치: 유지보수가 예약된 경우 인프라 및 워크로드를 평가하고 사용 사례에 가장 적합한 조치를 결정합니다. 시스템에서 유지보수 이벤트를 자동으로 처리하도록 하거나, 호스트 유지보수를 수동으로 시작하거나, 유지보수 전략을 오케스트레이션하는 등의 적절한 조치를 취합니다.
  3. 유지보수 이벤트 결과 확인: Compute Engine이 일정에 따라 유지보수 이벤트를 시작하거나 수동으로 시작할 때 유지보수 이벤트가 올바르게 시작되었는지 확인합니다.

예약된 호스트 유지보수 감지

예정된 유지보수 이벤트를 모니터링하고 감지하려면 GKE와 Compute Engine 모두의 알림을 확인해야 합니다.

유지보수 알림 및 이벤트 모니터링에 대한 자세한 내용은 유지보수 이벤트 모니터링을 참조하세요.

감지된 유지보수에 대한 조치

클러스터의 하나 이상의 노드에 예정된 유지보수 알림이 표시되면 다음 결정 트리를 사용하여 중단을 처리하는 가장 좋은 방법을 결정합니다.

  1. 자동 유지보수: Compute Engine이 일정에 따라 유지보수 이벤트를 시작하도록 합니다. VM은 중단이 거의 또는 전혀 없이 백그라운드에서 자동으로 라이브 마이그레이션됩니다.

    1. 호스트 VM이 라이브 마이그레이션을 지원하는 경우 유지보수 이벤트가 자동으로 발생하도록 하는 것이 좋습니다.
    2. 워크로드가 유휴 유연 노드에서 실행되는 경우 유지보수 시기를 자동으로 최적화할 수 있습니다. 기회 유지보수를 구성하여 이렇게 하면 자연스러운 유휴 시간 동안에만 필요한 업데이트가 트리거됩니다.

  2. 호스트 유지보수 이벤트 수동 시작: 다음 질문을 평가하여 중단을 수동으로 처리하는 가장 좋은 방법을 결정합니다.

    1. 영향을 받는 노드가 단일 VM 또는 격리된 VM인가요?

      • 예 (단일 VM 또는 격리된 VM을 실행 중임):
        • 정확한 타이밍 제어가 필요하지 않은 경우 Compute Engine이 일정에 따라 유지보수 이벤트를 시작하도록 합니다(기본 자동).
        • 예상치 못한 선점을 방지해야 하는 경우 편리한 시간(예: 트래픽이 적은 기간)에 개별 노드에서 호스트 유지보수 이벤트를 수동으로 시작 합니다.
      • 아니요 (가속기 노드 풀을 실행 중임): 다음 단계의 옵션 중 하나를 선택합니다.

    2. 사용 사례에 따라 다음 옵션 중 하나를 선택합니다.

      • 가속기 풀에서 결합된 AI/ML 학습 작업을 실행하는 경우: 병렬 전략을 구현합니다. 학습 상태를 체크포인트에 저장하고, 풀을 정상적으로 종료하고, 다시 시작하기 전에 호스트 업데이트와 GKE 클러스터 업그레이드를 동시에 실행합니다.

      • 가속기 풀에서 고가용성 AI/ML 서빙 또는 추론 엔드포인트를 실행하는 경우: 롤링 전략을 구현합니다. 활성 복제본을 사용하여 SLA를 보호하면서 영역 또는 풀 경계 내에서 롤링 일괄 처리로 예약된 호스트 유지보수 및 버전 업그레이드를 조정합니다.

단일 VM 또는 격리된 VM에서 호스트 유지보수 이벤트 수동 시작

활동이 적은 시간과 같이 일정에 맞는 경우 일정을 변경할 수 있는 유지보수를 수동으로 시작할 수 있습니다. 이렇게 하려면 다음 조건이 충족되는 경우 cloud.google.com/perform-maintenance=true 라벨을 적용합니다.

앞의 조건이 충족되면 노드 풀의 노드에서 노드 라벨 cloud.google.com/perform-maintenance를 true로 설정합니다. 예를 들면 다음과 같습니다.

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

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

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

유지보수 이벤트 결과 확인

예정된 유지보수 이벤트를 감지하고 가장 적합한 조치를 결정한 후 유지보수 이벤트 결과를 확인할 수 있습니다.

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

유지보수 이벤트가 시작되면 노드가 임박한 종료 전에 짧은 알림 시간과 함께 한 번 또는 여러 번 종료될 수 있습니다. 이 경우 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 노드의 중단 수를 보고합니다 (측정항목은 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}]))

중단을 최소화하기 위한 고급 구성

이 섹션에서는 중단을 최소화하도록 클러스터 및 워크로드를 구성하는 추가 도구를 설명합니다.

중단 처리 사용 설정

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

중단 처리를 사용 설정하려면 이 ConfigMap으로 maintenance-config.yaml이라는 파일을 만듭니다. 다음 명령어를 사용하여 클러스터에 ConfigMap을 적용합니다.

kubectl apply -f my-configmap.yaml

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에서 정상 노드 종료를 실행하는 방법을 보여줍니다.

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

다음 단계