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

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

이 문서에서는 GKE에서 노드 중단이 의미하는 바를 이해하고, Compute Engine 유지보수 알림을 모니터링하고, 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에는 라이브 마이그레이션으로 설정된 호스트 유지보수 정책이 있습니다. 즉, 실행 중인 워크로드가 일반적으로 거의 또는 전혀 중단되지 않습니다. 하지만 GPU 및 TPU가 연결된 VM, 18TiB 이상의 SSD가 있는 Z3 머신 유형, H4D 머신 유형, c4a-highmem-96-metal 머신 유형을 포함하여 특정 클래스의 VM에서는 라이브 마이그레이션을 지원하지 않습니다. 예를 들어 TPU 슬라이스 내 VM에서 호스트 이벤트가 발생하면 모든 유지보수 이벤트가 슬라이스 수준에서 조정되므로 전체 슬라이스가 중단된 후 다시 예약됩니다. 따라서 VM이 수백 개인 TPU 슬라이스를 만들면 이러한 모든 VM이 동일한 유지보수 이벤트 일정을 수신합니다.

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

유지보수 이벤트 관리

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

호스트 유지보수 이벤트 중 노드 중단을 관리하는 데는 3단계 워크플로가 사용됩니다.

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

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

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

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

  • Compute Engine에서 예정된 유지보수 보기: 노드와 기본 VM에 중단이 발생하는 호스트 이벤트가 예정되어 있고 이러한 이벤트가 활성화되면 Compute Engine에서 알림을 보냅니다. 알림에는 예정된 시작 시간, 이벤트 유형, 기타 세부정보가 포함됩니다.

  • GKE에서 예정된 유지보수 보기: GKE 버전 1.31.1-gke.2008000 이상에서는 예정된 유지보수 이벤트를 모니터링할 수 있습니다. 다음 머신 유형 및 GKE 버전의 예정된 이벤트를 모니터링할 수 있습니다.

    • GPU 또는 TPU가 연결된 머신 유형의 경우 1.31.1-gke.2008000 이상
    • SSD가 18TiB를 초과하는 Z3 머신 유형의 경우 1.32.4-gke.1376000 이상
    • H4D 머신 유형의 경우 1.32.6-gke.1060000 이상
    • c4a-highmem-96-metal의 경우 1.35.0-gke.2232000 이상

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

    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 엔드포인트에 액세스할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

  • Compute Engine은 예약된 유지보수 이벤트에 관한 알림을 발행합니다.
  • 기본 Compute Engine 유지보수 이벤트는 일정을 변경할 수 있습니다. 이벤트의 일정을 변경할 수 있는지 확인하려면 이벤트 메타데이터에서 can_reschedule=TRUE 알림을 확인하세요. 이벤트의 일정을 변경할 수 없는 경우 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 설정 값까지 줄어들 수 있습니다.

다음 단계