커스텀 컴퓨팅 클래스 정보

Autopilot Standard

이 페이지에서는 클러스터를 자동 확장할 때 커스텀 컴퓨팅 클래스를 사용하여 Google Kubernetes Engine(GKE)에서 프로비저닝하는 노드의 속성을 제어하는 방법을 설명합니다. 이 문서는 특정 워크로드가 요구사항을 충족하는 하드웨어에서 실행되도록 노드의 자동 확장 프로필을 선언적으로 정의하려는 플랫폼 관리자를 대상으로 합니다.

컴퓨팅 클래스 개요

GKE에서 컴퓨팅 클래스는 GKE가 워크로드를 실행하는 노드를 프로비저닝하는 데 사용하는 노드 속성의 집합으로 구성된 프로필입니다. 컴퓨팅 클래스는 고성능 노드를 프로비저닝하거나 운영비 절감을 위한 비용 최적화 구성을 우선시하는 등의 특정 최적화를 타겟팅할 수 있습니다. 커스텀 컴퓨팅 클래스를 사용하면 GKE에서 특정 워크로드의 요구사항을 최대한 충족하는 노드를 프로비저닝하는 데 사용하는 프로필을 정의할 수 있습니다.

커스텀 컴퓨팅 클래스는 버전 1.30.3-gke.1451000 이상에서 GKE Autopilot 모드와 GKE Standard 모드로 사용할 수 있으며 노드 속성과 자동 확장 우선순위를 정의하는 선언적 접근 방식을 제공합니다. 커스텀 컴퓨팅 클래스는 기본적으로 요건에 맞는 모든 GKE 클러스터에서 구성하고 사용할 수 있습니다.

커스텀 컴퓨팅 클래스의 이점

커스텀 컴퓨팅 클래스는 다음과 같은 이점을 제공합니다.

대체 컴퓨팅 우선순위: 각 컴퓨팅 클래스에서 GKE가 우선시할 노드 구성의 계층 구조를 정의합니다. 가장 선호되는 구성을 사용할 수 없는 경우 GKE는 계층 구조의 다음 구성을 자동으로 선택합니다. 이 대체 모델을 사용하면 컴퓨팅 리소스를 사용할 수 없는 경우에도 최적화된 하드웨어에서 워크로드를 실행하면서 예약 지연을 최소화할 수 있습니다.
세분화된 자동 확장 제어: 특정 워크로드에 가장 적합한 노드 구성을 정의합니다. GKE는 확장 중에 노드를 만들 때 이러한 구성을 우선시합니다.
선언적 인프라 구성: GKE가 특정 워크로드 요구사항에 맞는 노드를 자동으로 만들도록 인프라 관리에 선언적 접근 방식을 채택합니다.
활성 마이그레이션: 더 선호되는 머신 구성의 컴퓨팅 리소스를 해당 위치에서 사용할 수 있게 되면 GKE는 선호되는 구성을 사용하는 새 노드로 워크로드를 자동으로 마이그레이션합니다.
비용 최적화: 스팟 VM과 같이 비용 효율적인 노드 유형을 우선시하여 클러스터 비용을 줄입니다.
네임스페이스의 기본 컴퓨팅 클래스: 각 Kubernetes 네임스페이스의 워크로드가 특정 컴퓨팅 클래스를 요청하지 않아도 최적화된 하드웨어에서 실행되도록 해당 네임스페이스에 기본 컴퓨팅 클래스를 설정합니다.
커스텀 노드 통합 기준점: 노드의 커스텀 리소스 사용량 기준점을 정의합니다. 특정 노드의 리소스 사용량이 기준점 미만이면 GKE는 워크로드를 사용 가능한 유사 노드로 통합하고 사용률이 낮은 노드를 축소하려고 시도합니다.

커스텀 컴퓨팅 클래스의 사용 사례

다음과 같은 시나리오에서 커스텀 컴퓨팅 클래스를 사용하는 것이 좋습니다.

특정 GPU 구성에서 AI/ML 워크로드를 실행하려고 합니다.
특정 팀에서 실행하는 워크로드의 기본 하드웨어 구성을 설정하여 애플리케이션 운영자의 오버헤드를 줄이려고 합니다.
특정 Compute Engine 머신 시리즈 또는 하드웨어 구성에서 최적의 성능을 발휘하는 워크로드를 실행합니다.
고성능, 비용 최적화, 고가용성과 같은 특정 비즈니스 요구사항을 충족하는 하드웨어 구성을 선언하려고 합니다.
워크로드가 항상 요구사항에 맞는 머신에서 실행되도록 컴퓨팅 리소스가 부족할 때 GKE가 특정 하드웨어 구성을 계층적으로 대체 사용했으면 합니다.
비용 예측성과 워크로드 실행의 안정성을 높이기 위해 엔터프라이즈 Fleet 전체에서 최적의 구성을 중앙에서 결정하려고 합니다.

제한사항

Autopilot 모드 또는 자동 프로비저닝된 Standard 모드 노드 풀에서는 Compute Engine 용량 예약과 함께 커스텀 컴퓨팅 클래스를 사용할 수 없습니다. 수동으로 만든 Standard 모드 노드 풀은 용량 예약을 지원합니다.

커스텀 컴퓨팅 클래스의 작동 방식

커스텀 컴퓨팅 클래스는 Google Cloud 인프라를 프로비저닝하는 Kubernetes 커스텀 리소스입니다. 클러스터에서 ComputeClass 객체를 정의한 다음 해당 컴퓨팅 클래스를 워크로드에서 요청하거나 Kubernetes 네임스페이스의 기본값으로 설정합니다. 컴퓨팅 클래스를 요청하는 워크로드를 배포하면 GKE는 컴퓨팅 클래스 요구사항을 충족하는 노드에 포드를 배치하려고 시도합니다.

커스텀 컴퓨팅 클래스를 Fleet에 최적화하려면 다음 가이드라인을 고려하세요.

애플리케이션별 하드웨어 요구사항을 비롯하여 Fleet의 컴퓨팅 요구사항을 파악합니다.
각 컴퓨팅 클래스의 설계를 주도할 테마를 결정합니다. 예를 들어 성능 최적화 컴퓨팅 클래스에는 높은 CPU 머신 유형만 사용하는 대체 전략을 사용할 수 있습니다.
워크로드에 가장 적합한 Compute Engine 머신 계열 및 머신 시리즈를 결정합니다. 자세한 내용은 머신 계열 리소스 및 비교 가이드를 참조하세요.
워크로드가 항상 유사한 머신 구성을 사용하는 노드에서 실행되도록 각 컴퓨팅 클래스 내에 대체 전략을 수립합니다. 예를 들어 N4 머신 시리즈를 사용할 수 없는 경우 N2 머신으로 대체할 수 있습니다.

전체 커스텀 리소스 정의 보기

ComputeClass 커스텀 리소스의 전체 커스텀 리소스 정의(CRD)를 보려면 다음 명령어를 실행합니다.

kubectl describe crd computeclasses.cloud.google.com

출력에는 지원되는 모든 필드와 필드 간의 관계를 포함한 전체 CRD가 표시됩니다. 커스텀 컴퓨팅 클래스를 더 잘 이해하려면 이 문서를 읽는 동안 이 정의를 참조하세요.

커스텀 컴퓨팅 클래스 계획

클러스터에서 커스텀 컴퓨팅 클래스를 효과적으로 계획, 배포, 사용하려면 다음 단계를 따르세요.

대체 컴퓨팅 우선순위 선택: GKE가 컴퓨팅 클래스에 대해 만드는 노드의 속성을 관리하는 일련의 규칙을 정의합니다.
GKE Standard 노드 풀 및 컴퓨팅 클래스 구성: Standard 모드 클러스터의 경우 노드 풀에서 컴퓨팅 클래스를 사용하는 데 필요한 구성 단계를 수행합니다.
우선순위 규칙이 적용되지 않는 경우의 확장 동작 정의: 필요한 경우 우선순위 규칙을 충족하는 노드를 프로비저닝할 수 없을 때 GKE에서 취할 조치를 지정합니다.
노드 통합을 위한 자동 확장 매개변수 설정: GKE에서 워크로드를 통합하고 사용률이 낮은 노드를 삭제할 시점을 지정합니다.
우선순위가 더 높은 노드로의 활성 마이그레이션 구성: 필요한 경우 GKE에서 하드웨어가 사용 가능해지면 더 선호되는 노드로 워크로드를 이동하도록 지정합니다.

대체 컴퓨팅 우선순위 선택

커스텀 컴퓨팅 클래스를 사용할 때의 주요 이점은 리소스 소진 및 할당량 제한과 같은 요인으로 인해 선호되는 노드를 사용할 수 없는 경우의 대체 전략을 제어할 수 있다는 것입니다.

커스텀 컴퓨팅 클래스에서 우선순위 규칙 목록을 정의하여 대체 전략을 만듭니다. 클러스터를 수직 확장해야 할 때 GKE는 첫 번째 우선순위 규칙과 일치하는 노드를 우선적으로 만듭니다. GKE가 이러한 노드를 만들 수 없는 경우 다음 우선순위 규칙으로 대체되며, GKE에서 클러스터 수직 확장에 성공하거나 모든 규칙이 소진될 때까지 이 프로세스를 반복합니다. 모든 규칙이 소진되면 GKE는 우선순위 규칙이 적용되지 않는 경우 확장 동작 정의에 설명된 기본 동작이나 지정된 동작을 기반으로 노드를 만듭니다.

우선순위 규칙

ComputeClass 커스텀 리소스의 spec.priorities 필드에서 우선순위 규칙을 정의합니다. priorities 필드의 각 규칙은 프로비저닝할 노드의 속성을 설명합니다. GKE는 priorities 필드를 순서대로 처리합니다. 즉, 필드의 첫 번째 항목이 노드 프로비저닝에서 가장 높은 우선순위를 갖습니다.

우선순위 규칙의 유형에 따라서는 GKE가 노드를 프로비저닝할 때 사용할 스팟 VM 또는 최소 CPU 용량과 같은 머신 속성을 추가로 지정할 수 있습니다. priorities 필드는 다음과 같은 우선순위 규칙 유형을 지원합니다.

machineFamily: n2 또는 c3 등의 Compute Engine 머신 시리즈를 사용하여 노드를 정의합니다.
machineType: 사전 정의된 Compute Engine 머신 유형(예: n2-standard-4)을 사용하여 노드를 정의합니다.
nodepools: GKE Standard 클러스터에서 GKE가 노드를 프로비저닝해야 하는 컴퓨팅 클래스와 연결된 수동으로 만든 노드 풀의 목록을 제공합니다.

machineFamily 규칙 유형

machineFamily 필드는 n2 또는 c3 등의 Compute Engine 머신 시리즈를 허용합니다. 지정하지 않는 경우 기본값은 e2입니다. machineFamily 규칙 유형과 함께 다음 필드를 사용할 수 있습니다.

spot: 스팟 VM. 기본값은 false입니다.
minCores: 노드당 최소 vCPU 수. 기본값은 0입니다.
minMemoryGb: 노드당 최소 메모리. 기본값은 0입니다.
storage.bootDiskKMSKey: 부팅 디스크 암호화에 사용할 Cloud Key Management Service 키의 경로입니다.

다음 예시에서는 machineFamily 우선순위 규칙을 보여줍니다.

priorities:
- machineFamily: n2
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

machineType 규칙 유형

machineType 필드는 n2-standard-32 등의 Compute Engine 사전 정의된 머신 유형을 허용합니다. 머신 유형은 지정된 모든 GPU를 지원해야 합니다.

machineType 규칙 유형과 함께 다음 필드를 사용할 수 있습니다.

spot: 스팟 VM을 사용합니다. 기본값은 false입니다.
storage: 노드 스토리지를 구성합니다.
- storage.bootDiskType: 부팅 디스크 유형
- storage.bootDiskKMSKey: 부팅 디스크 암호화에 사용할 Cloud KMS 키의 경로
- storage.bootDiskSize: 노드 부팅 디스크의 크기(GB)
- storage.localSSDCount: 노드에 연결할 로컬 SSD 개수. 지정된 경우 1 이상이어야 합니다.
gpu: GPU를 구성합니다.
- gpu.type: GPU 유형(예: nvidia-l4). 자세한 내용은 Autopilot에서 GPU 워크로드 배포를 참조하세요.
- gpu.count: 연결할 GPU 개수. GPU 유형별로 지원되는 수량은 지원되는 GPU 수량을 참조하세요.

다음 예시에서는 n2-standard-32 머신 유형의 machineType 규칙을 보여줍니다.

priorities:
- machineType: n2-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1

다음 예시에서는 GPU의 machineType 규칙을 보여줍니다.

priorities:
- machineType: g2-standard-16
  spot: false
  gpu:
    type: nvidia-l4
    count: 1

nodepools 규칙 유형

nodepools 필드는 GKE가 대기 중인 포드를 만들려고 시도하는 기존 노드 풀의 목록을 가져옵니다. GKE는 이 필드의 값을 순서대로 처리하지 않습니다. 동일한 우선순위 규칙 항목에서 이 필드와 함께 다른 머신 속성을 지정할 수 없습니다. 이 필드는 GKE Standard 모드에서만 지원됩니다. 자세한 사용 방법은 컴퓨팅 클래스 정의에서 특정 노드 풀 타겟팅을 참조하세요.

GKE에서 우선순위 규칙을 사용하여 노드를 만드는 방법

컴퓨팅 클래스를 요청하는 워크로드를 배포할 때 새 노드가 필요한 경우 GKE는 ComputeClass 사양의 priorities 필드에 있는 규칙 목록을 순서대로 처리합니다.

예를 들어 다음 사양을 고려해 보세요.

spec:
  ...
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false

이러한 우선순위 규칙이 있는 컴퓨팅 클래스를 요청하는 워크로드를 배포하면 GKE는 다음과 같이 노드를 일치시킵니다.

GKE는 이 컴퓨팅 클래스와 연결된 기존 노드에 포드를 배치합니다.
기존 노드가 포드를 수용할 수 없는 경우 GKE는 N2 머신 시리즈를 사용하고, 스팟 VM이며, vCPU가 64개 이상인 새 노드를 프로비저닝합니다.
리전에서 vCPU가 64개 이상인 N2 스팟 VM을 사용할 수 없는 경우 GKE는 코어 수와 관계없이 포드를 수용할 수 있는 N2 스팟 VM을 사용하는 새 노드를 프로비저닝합니다.
리전에서 사용할 수 있는 N2 스팟 VM이 없는 경우 GKE는 새 주문형 N2 VM을 프로비저닝합니다.
위의 규칙 중 어느 규칙도 충족할 수 없는 경우 GKE는 우선순위 규칙이 적용되지 않는 경우 확장 동작 정의 섹션의 로직을 따릅니다.

GKE Standard 노드 풀 및 컴퓨팅 클래스

GKE Standard 모드를 사용하는 경우 컴퓨팅 클래스 포드가 정상적으로 예약되도록 수동 구성을 수행해야 할 수 있습니다.

노드 자동 프로비저닝으로 관리되는 노드 풀: 수동 구성이 필요하지 않습니다. 노드 자동 프로비저닝은 컴퓨팅 클래스 구성 단계를 자동으로 수행합니다. 자세한 내용은 노드 자동 프로비저닝 및 컴퓨팅 클래스를 참조하세요.
수동으로 생성된 노드 풀: 수동 구성이 필요합니다. 노드를 특정 컴퓨팅 클래스와 연결하려면 수동으로 만든 노드 풀에 노드 라벨과 노드 taint를 추가해야 합니다. 자세한 내용은 컴퓨팅 클래스 사용을 위해 수동으로 만든 노드 풀 구성을 참조하세요.

컴퓨팅 클래스 사용을 위해 수동으로 만든 노드 풀 구성

GKE Standard 클러스터에 노드 자동 프로비저닝 없이 수동으로 만든 노드 풀이 있는 경우 이러한 노드 풀을 특정 컴퓨팅 클래스와 연결되도록 구성해야 합니다. GKE는 특정 컴퓨팅 클래스를 요청하는 포드를 해당 컴퓨팅 클래스와 연결된 노드 풀의 노드에만 예약합니다. 노드 자동 프로비저닝으로 만든 GKE Autopilot 모드 및 GKE Standard 모드 노드 풀은 이 구성을 자동으로 수행합니다.

수동으로 만든 노드 풀을 컴퓨팅 클래스와 연결하려면 생성 또는 업데이트 중에 다음과 같이 --node-labels 플래그와 --node-taints 플래그를 지정하여 노드 풀에 노드 라벨 및 노드 taint를 추가합니다.

노드 라벨: cloud.google.com/compute-class=COMPUTE_CLASS
Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

이러한 속성에서 COMPUTE_CLASS는 커스텀 컴퓨팅 클래스의 이름입니다.

예를 들어 다음 명령어는 기존 노드 풀을 업데이트하고 dev-class 컴퓨팅 클래스와 연결합니다.

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class" \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

클러스터의 각 노드 풀을 하나의 커스텀 컴퓨팅 클래스와 연결할 수 있습니다. GKE가 이러한 수동으로 생성된 노드 풀에 예약하는 포드는 자동 확장 이벤트 중에 해당 노드 풀 내에서만 노드 생성을 트리거합니다.

노드 자동 프로비저닝 및 컴퓨팅 클래스

커스텀 컴퓨팅 클래스와 함께 노드 자동 프로비저닝을 사용하면 GKE가 우선순위 규칙에 따라 노드 풀을 자동으로 만들고 삭제하도록 할 수 있습니다.

컴퓨팅 클래스와 함께 노드 자동 프로비저닝을 사용하려면 다음을 실행해야 합니다.

클러스터에서 노드 자동 프로비저닝이 사용 설정되어 있는지 확인합니다.
ComputeClass 사양에 enabled: true 값이 있는 nodePoolAutoCreation 필드를 추가합니다.

그러면 GKE는 새 노드 풀에 노드 자동 프로비저닝을 구성하는 컴퓨팅 클래스를 사용하는 포드를 배치할 수 있습니다. GKE는 클러스터 크기 및 포드 요구사항과 같은 요인에 따라 기존 노드 풀을 수직 확장할지 아니면 새 노드 풀을 만들지를 결정합니다. 노드 자동 프로비저닝을 구성하지 않는 컴퓨팅 클래스가 있는 포드는 기존 노드 풀을 계속 수직 확장하기만 합니다.

동일한 클러스터에서 수동으로 만든 노드 풀과 상호작용하는 컴퓨팅 클래스와 함께 노드 자동 프로비저닝과 상호작용하는 컴퓨팅 클래스를 사용할 수 있습니다.

노드 자동 프로비저닝과의 다음 상호작용을 고려해 보세요.

머신 계열 또는 스팟 VM 노드 선택기는 컴퓨팅 클래스 동작과 충돌하므로 사용할 수 없습니다. GKE는 컴퓨팅 클래스를 요청하면서 스팟 VM 또는 특정 머신 시리즈도 요청하는 모든 포드를 거부합니다.
nodepools 필드를 사용하여 기존 노드 풀을 참조하는 컴퓨팅 클래스에 노드 자동 프로비저닝을 구성할 수 있습니다. 노드 자동 프로비저닝은 우선순위를 순서대로 처리하고 포드를 배치하기 위해 기존 노드 풀을 수직 확장하려고 시도합니다.

다음 예시는 수동으로 만든 노드 풀과 노드 자동 프로비저닝이 모두 있는 클러스터입니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n2
  - machineFamily: n2d
  nodePoolAutoCreation:
    enabled: true

이 예시에서 GKE는 다음을 시도합니다.

manually-created-pool 노드 풀에 새 노드를 만듭니다.
N2 노드를 기존 N2 노드 풀에 프로비저닝하거나 새 노드 풀을 만들어 프로비저닝합니다.
GKE가 N2 노드를 만들 수 없는 경우 기존 N2D 노드 풀을 수직 확장하거나 새 N2D 노드 풀을 만들려고 시도합니다.

컴퓨팅 클래스 정의에서 특정 노드 풀 타겟팅

priorities.nodepools 필드를 사용하면 클러스터 자동 확장을 사용하는 GKE Standard 클러스터에서 GKE가 특정 순서 없이 포드를 예약하려고 시도하는 수동으로 만든 노드 풀의 목록을 지정할 수 있습니다. 이 필드는 노드 풀 목록만 지원하며, 동일한 우선순위 규칙에서 머신 시리즈와 같은 추가 머신 속성을 지정할 수 없습니다. 이름이 지정된 노드 풀이 있는 컴퓨팅 클래스를 요청하는 워크로드를 배포하면 GKE는 대기 중인 포드를 해당 노드 풀에 예약하려고 시도합니다. GKE는 이러한 노드 풀에 새 노드를 만들어 포드를 배치할 수 있습니다.

priorities.nodepools 필드에 지정하는 노드 풀은 컴퓨팅 클래스 사용을 위해 수동으로 만든 노드 풀 구성 섹션에 설명된 대로 노드 라벨과 노드 taint를 사용하여 해당 컴퓨팅 클래스와 반드시 연결되어야 합니다.

nodepools 필드에 지정하는 노드 풀 목록에는 우선순위가 없습니다. 이름이 지정된 노드 풀의 대체 순서를 구성하려면 개별 priorities.nodepools 항목을 여러 개 지정해야 합니다. 예를 들어 다음 사양을 고려해 보세요.

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

이 예시에서 GKE는 먼저 이 컴퓨팅 클래스를 요청하는 대기 중인 포드를 컴퓨팅 클래스로 라벨이 지정된 노드 풀의 기존 노드에 배치하려고 시도합니다. 기존 노드를 사용할 수 없는 경우 GKE는 새 노드를 pool1 또는 pool2에 프로비저닝하려고 시도합니다. GKE는 이러한 노드 풀에 새 노드를 프로비저닝할 수 없는 경우 새 포드를 pool3에 프로비저닝하려고 시도합니다.

우선순위 규칙이 적용되지 않는 경우 확장 동작 정의

ComputeClass 커스텀 리소스를 사용하면 우선순위 규칙을 충족할 수 있는 노드가 없는 경우 GKE에서 취할 조치를 지정할 수 있습니다. 사양의 whenUnsatisfiable 필드는 다음 값을 지원합니다.

ScaleUpAnyway: 클러스터의 기본 머신 구성을 사용하는 새 노드를 만듭니다. 이는 기본 동작입니다.
- Autopilot 클러스터에서 GKE는 노드 머신 구성과 관계없이 새 노드 또는 기존 노드에 포드를 배치합니다.
- 노드 자동 프로비저닝을 사용하지 않는 Standard 클러스터에서 GKE는 지정된 컴퓨팅 클래스와 일치하는 라벨과 taint를 정의하는 수동으로 만든 노드 풀을 수직 확장하려고 시도합니다.
- 노드 자동 프로비저닝을 사용하는 Standard 클러스터에서 GKE는 기본 E2 머신 시리즈를 사용하여 포드를 배치하는 새 노드 풀을 만들 수 있습니다.
DoNotScaleUp: 컴퓨팅 클래스 요구사항을 충족하는 노드를 사용할 수 있을 때까지 포드를 Pending 상태로 둡니다.

노드 통합을 위한 자동 확장 매개변수 설정

기본적으로 GKE는 워크로드 실행 시 사용률이 낮은 노드를 삭제하고 용량에 여유가 있는 다른 노드에 해당 워크로드를 통합합니다. 컴퓨팅 클래스를 사용하는 모든 클러스터는 클러스터 자동 확장 처리를 사용하거나 Autopilot 클러스터이므로 이 동작은 모든 컴퓨팅 클래스의 기본 동작입니다. 노드 통합 중에 GKE는 사용률이 낮은 노드를 드레이닝하고 워크로드를 다른 노드에 다시 만든 다음 드레이닝된 노드를 삭제합니다.

노드 삭제 시점과 기준은 자동 확장 프로필에 따라 다릅니다. 커스텀 컴퓨팅 클래스 정의에서 autoscalingPolicy 섹션을 사용하면 노드 삭제 및 워크로드 통합을 트리거하는 리소스 사용률 부족 기준점을 미세 조정할 수 있습니다. 다음 매개변수를 미세 조정할 수 있습니다.

consolidationDelayMinutes: GKE에서 사용률이 낮은 노드를 삭제하기 전에 기다릴 시간(분)
consolidationThreshold: CPU 및 메모리의 사용률 기준점(노드의 사용 가능한 리소스에 대한 백분율). GKE는 리소스 사용률이 이 기준점 미만일 때만 노드를 삭제 대상으로 간주합니다.
gpuConsolidationThreshold: GPU의 사용률 기준점(노드의 사용 가능한 리소스에 대한 백분율). GKE는 리소스 사용률이 이 기준점 미만일 때만 노드를 삭제 대상으로 간주합니다. GKE에서 연결된 GPU의 사용률이 100%가 아닌 노드를 모두 통합하도록 100 또는 0으로 설정하는 것이 좋습니다.

다음 예시를 참조하세요.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

이 구성에서 GKE는 미사용 노드를 5분 후에 삭제하며, CPU 및 메모리 사용률이 모두 70% 미만인 노드만 통합 대상으로 간주됩니다.

우선순위가 더 높은 노드로의 활성 마이그레이션 구성

커스텀 컴퓨팅 클래스의 선택적 자동 확장 기능인 활성 마이그레이션은 컴퓨팅 클래스 대체 우선순위 목록에서 더 낮은 기존 노드를 해당 우선순위 목록에서 더 높은 새 노드로 자동으로 대체합니다. 따라서 처음에는 GKE가 선호도가 낮은 노드에서 포드를 실행했더라도 실행 중인 모든 포드가 결국 해당 컴퓨팅 클래스의 가장 선호되는 노드에서 실행됩니다.

활성 마이그레이션이 발생하면 GKE는 컴퓨팅 클래스 우선순위 규칙에 따라 새 노드를 만든 다음 우선순위가 낮아서 더 이상 사용되지 않는 노드를 드레이닝하고 삭제합니다. 워크로드 중단을 최소화하기 위해 마이그레이션은 점진적으로 진행됩니다. 활성 마이그레이션에는 다음과 같은 고려사항이 있습니다.

Standard 클러스터에서 노드 자동 프로비저닝을 사용 설정한 경우 기존 노드 풀이 커스텀 컴퓨팅 클래스에 정의된 우선순위가 더 높은 기준을 충족하지 못하면 활성 마이그레이션에서 새 노드 풀 생성을 트리거할 수 있습니다.
핵심 워크로드가 중단되지 않도록 활성 마이그레이션에서는 다음 포드를 이동하지 않습니다.
- PodDisruptionBudget을 설정하며 이동으로 인해 PodDisruptionBudget이 초과되는 포드
- cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 주석이 있는 포드

다음 컴퓨팅 클래스 사양 예시에서는 N2D 노드보다 N2 노드를 우선시합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n2
  - machineFamily: n2d
  activeMigration:
    optimizeRulePriority: true

이 컴퓨팅 클래스로 포드를 배포할 때 N2 노드를 사용할 수 없었다면 GKE는 N2D 노드를 대체 옵션으로 사용했을 것입니다. 이후에 할당량이 상향 조정되거나 해당 위치에서 N2 VM을 사용할 수 있게 되는 등의 상황으로 N2 노드를 프로비저닝할 수 있게 되면 GKE는 새 N2 노드를 만들고 포드를 기존 N2D 노드에서 새 N2 노드로 점진적으로 마이그레이션합니다. 그런 다음 GKE에서 더 이상 사용되지 않는 N2D 노드를 삭제합니다.

워크로드에서 컴퓨팅 클래스 요청

커스텀 컴퓨팅 클래스 설계를 완료한 후 포드에서 이를 사용하려면 포드 사양에서 해당 컴퓨팅 클래스를 명시적으로 요청해야 합니다. 필요한 경우 특정 Kubernetes 네임스페이스에서 컴퓨팅 클래스를 기본값으로 설정할 수 있습니다. 이렇게 하면 포드가 다른 컴퓨팅 클래스를 요청하지 않는 한 해당 네임스페이스의 포드가 해당 컴퓨팅 클래스를 사용합니다.

GKE에서 컴퓨팅 클래스를 요청하고 사용하는 방법은 커스텀 컴퓨팅 클래스로 자동 확장된 노드 속성 제어를 참조하세요.

다음 단계

GKE Autopilot의 기타 워크로드 배포 권장사항 알아보기