맞춤 ComputeClass 정보

자체 ComputeClass를 만들어 클러스터를 자동 확장할 때 Google Kubernetes Engine (GKE)에서 프로비저닝하는 노드의 속성을 제어할 수 있습니다. 이 문서는 특정 워크로드가 요구사항을 충족하는 하드웨어에서 실행되도록 노드의 자동 확장 프로필을 선언적으로 정의하려는 플랫폼 관리자를 대상으로 합니다. ComputeClass에 대한 자세한 내용은 GKE ComputeClass 정보를 참고하세요.

ComputeClasses 개요

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

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

맞춤 ComputeClass의 이점

커스텀 ComputeClass는 다음과 같은 이점을 제공합니다.

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

커스텀 ComputeClass 사용 사례

다음과 같은 시나리오에서 맞춤 ComputeClass를 사용하는 것이 좋습니다.

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

맞춤 ComputeClass의 작동 방식

커스텀 ComputeClass는Google Cloud 인프라를 프로비저닝하는 Kubernetes 커스텀 리소스입니다. 클러스터에서 ComputeClass 객체를 정의한 다음 해당 ComputeClass를 워크로드에서 요청하거나 Kubernetes 네임스페이스의 기본값으로 설정합니다. 일치하는 워크로드에 새 인프라가 필요한 경우 GKE는 ComputeClass 정의에 설정된 우선순위에 따라 새 노드를 프로비저닝합니다.

ComputeClasses에서 설정한 속성은 GKE가 워크로드를 실행할 새 노드를 구성하는 방법을 정의합니다. 기존 ComputeClass를 수정하면 GKE가 해당 ComputeClass에 대해 만드는 모든 향후 노드는 수정된 구성을 사용합니다. GKE는 수정사항에 맞게 기존 노드의 구성을 소급하여 변경하지 않습니다.

맞춤 ComputeClass는 자동 확장 결정에 영향을 미치지만 kube-scheduler에서는 고려하지 않습니다. 포드 예약 중에 기존 노드가 다양한 우선순위에 걸쳐 사용 가능하더라도 스케줄러가 맞춤 ComputeClass 우선순위가 더 높은 노드에 우선순위를 부여하지 않을 수 있습니다.

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

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

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

모든 필드와 관계를 포함하여 ComputeClass 커스텀 리소스의 최신 커스텀 리소스 정의 (CRD)를 보려면 ComputeClass 참조 문서를 참고하세요.

다음 명령어를 실행하여 클러스터에서 CRD를 볼 수도 있습니다.

kubectl describe crd computeclasses.cloud.google.com

커스텀 ComputeClass 계획

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

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

대체 컴퓨팅 우선순위 선택

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

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

Compute Engine 머신 시리즈마다 지원되는 기술과 기능이 다릅니다. 이전 세대의 머신 시리즈는 최신 세대와 동일한 스토리지 유형을 지원하지 않을 수 있습니다. 영구 데이터를 사용하는 스테이트풀 워크로드를 실행하는 경우 여러 세대의 머신 시리즈에 걸쳐 있는 ComputeClass를 사용하지 마세요. GKE에서 해당 스토리지 유형을 지원하지 않는 머신 유형에 워크로드를 배치하면 워크로드가 영구 데이터에 액세스하지 못할 수 있습니다. 자세한 내용은 머신 시리즈 비교 표에서 특정 스토리지 유형을 필터링하세요.

우선순위 규칙

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

우선순위 규칙에는 두 가지 유형이 있습니다.

  • 선언적 규칙 유형: 노드 특성을 사용하여 프로비저닝할 노드를 설명합니다.

  • 노드 풀 규칙 유형: GKE Standard 클러스터에서 GKE가 노드를 프로비저닝해야 하는 ComputeClass와 연결된 수동으로 만든 노드 풀의 목록을 제공합니다.

선언적 우선순위 규칙

선언적 우선순위 규칙을 사용하면 GKE가 노드를 프로비저닝할 때 사용할 머신 속성(예: 머신 계열 또는 유형, 스팟 VM, 액셀러레이터 옵션, 스토리지 옵션, 예약, 최소 리소스 요구사항)을 지정할 수 있습니다. 지원되는 필드의 전체 집합은 ComputeClass CRD 참조를 확인하세요.

machineFamily 구성

machineFamily 필드는 n4 또는 c4 등의 Compute Engine 머신 시리즈를 허용합니다. 지정하지 않는 경우 기본값은 e2입니다.

machineFamily 필드와 함께 다른 spec.priorities fields를 사용하여 컴퓨팅 요구사항을 선언적으로 정의할 수 있습니다. 예를 들면 다음과 같습니다.

  • spot: 스팟 VM. 기본값은 false입니다.
  • minCores: 노드당 최소 vCPU 수. 기본값은 0입니다.
  • minMemoryGb: 노드당 최소 메모리. 기본값은 0입니다.
  • storage.bootDiskKMSKey: 부팅 디스크 암호화에 사용할 Cloud Key Management Service 키의 경로입니다.
  • storage.secondaryBootDisks: 머신러닝 (ML) 모델이나 컨테이너 이미지와 같은 데이터로 GKE 노드를 미리 로드하는 데 사용되는 영구 디스크입니다. GKE 버전 1.31.2-gke.1105000 이상이 필요합니다. 클러스터에서 사용할 보조 부팅 디스크를 설정하려면 보조 부팅 디스크 구성을 참고하세요.
    • storage.secondaryBootDisks.diskImageName: 미리 로드할 디스크 이미지의 이름입니다.
    • storage.secondaryBootDisks.project: 디스크 이미지가 속한 프로젝트의 이름입니다. 이 값을 지정하지 않으면 기본값은 클러스터 프로젝트입니다.
    • storage.secondaryBootDisks.mode: 보조 부팅 디스크를 사용해야 하는 모드입니다. 이 값이 CONTAINER_IMAGE_CACHE로 설정되면 보조 부팅 디스크가 컨테이너 이미지 캐시로 사용됩니다. 값은 CONTAINER_IMAGE_CACHE 또는 MODE_UNSPECIFIED과 같아야 합니다. 이 값을 지정하지 않으면 기본값은 MODE_UNSPECIFIED입니다.
  • placement: 머신 배치에 관한 세부정보입니다.

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

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset
machineType 구성

machineType 필드는 n4-standard-32 등의 Compute Engine 사전 정의된 머신 유형이나 n4-custom-8-20480 등의 커스텀 머신 유형 문자열을 허용합니다. 커스텀 머신 유형을 사용하려면 GKE 버전 1.33.2-gke.1111000 이상이 필요합니다.

machineType 필드와 함께 다른 spec.priorities 필드를 지정하여 컴퓨팅 요구사항을 선언적으로 정의할 수 있습니다. 예를 들면 다음과 같습니다.

  • spot: 스팟 VM을 사용합니다. 기본값은 false입니다.
  • storage: 노드 스토리지를 구성합니다.
    • storage.bootDiskType: 부팅 디스크 유형 Autopilot에서는 bootDiskType의 pd-balanced 유형만 지원됩니다.
    • storage.bootDiskKMSKey: 부팅 디스크 암호화에 사용할 Cloud KMS 키의 경로
    • storage.bootDiskSize: 노드 부팅 디스크의 크기(GB)
    • storage.localSSDCount: 노드에 연결할 로컬 SSD 개수. 지정된 경우 1 이상이어야 합니다.

다음 예시에서는 machineType를 사용하여 n4-standard-32 머신 유형을 프로비저닝하는 우선순위 규칙을 보여줍니다.

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

우선순위 규칙에서 GPU를 선택하려면 우선순위 규칙의 gpu 필드에 GPU의 유형, 수, driverVersion (선택사항)을 지정합니다. 다음 필드가 지원됩니다.

  • gpu.type: GPU 유형(예: nvidia-l4). 자세한 내용은 Autopilot 또는 Standard를 사용하여 GPU 지원 선택을 참고하세요.
  • gpu.count: 연결할 GPU 개수. GPU 유형별로 지원되는 수량은 지원되는 GPU 수량을 참조하세요.
  • gpu.driverVersion: 설치할 NVIDIA 드라이버 버전입니다. default 또는 latest여야 합니다. GKE 버전 1.31.1-gke.1858000 이상이 필요합니다.

gpu 필드와 함께 스팟 VM, 스토리지 옵션, 예약과 같은 다른 spec.priorities 필드를 지정할 수도 있습니다.

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

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true
TPU 구성

GKE 버전 1.31.2-gke.1518000 이상 필요

우선순위 규칙에서 TPU를 선택하려면 우선순위 규칙의 tpu 필드에 TPU의 유형, 수, 토폴로지를 지정합니다. 다음 필드는 필수입니다.

  • tpu.type: TPU 유형입니다(예: tpu-v5p-slice). 자세한 내용은 GKE Autopilot의 TPU 가용성을 참고하세요.
  • tpu.count: 연결할 TPU 수입니다.
  • tpu.topology: 사용할 TPU 토폴로지입니다(예: "2x2x1"). 자세한 내용은 Autopilot 토폴로지 선택을 참고하세요.

우선순위 규칙에서 tpu 필드와 함께 다른 spec.priorities 필드를 지정할 수도 있습니다. 예를 들면 다음과 같습니다.

  • spot: 스팟 VM을 사용합니다. 기본값은 false입니다.
  • storage: 노드 스토리지를 구성합니다.
    • storage.bootDiskType: 부팅 디스크 유형
    • storage.bootDiskKMSKey: 부팅 디스크 암호화에 사용할 Cloud KMS 키의 경로
    • storage.bootDiskSize: 노드 부팅 디스크의 크기(GB)
  • reservations: Compute Engine 예약을 사용합니다. 자세한 내용은 Compute Engine 예약 사용 섹션을 참고하세요.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

이 예에서는 다음과 같은 대체 동작을 정의합니다.

  1. GKE는 reservation-project 프로젝트에서 tpu-reservation라는 공유 Compute Engine 예약을 사용하여 16노드 멀티 호스트 TPU v5p 슬라이스를 프로비저닝하려고 시도합니다.
  2. 예약에 사용 가능한 TPU가 없으면 GKE는 Spot VM에서 실행되는 16노드 멀티 호스트 TPU v5p 슬라이스를 프로비저닝하려고 시도합니다.
  3. 위의 규칙 중 어느 규칙도 충족할 수 없는 경우 GKE는 우선순위 규칙이 적용되지 않는 경우 확장 동작 정의 섹션의 로직을 따릅니다.

TPU 커스텀 ComputeClass를 클러스터에 배포한 후 워크로드에서 해당 커스텀 ComputeClass를 선택합니다.

또한 TPU 워크로드의 경우 다음을 수행할 수 있습니다.

가속기 및 머신 형태 사양

선언적 가속기 구성은 예약과 함께 사용하지 않는 한 machineType 또는 machineFamily 필드를 명시적으로 지정하지 않아도 됩니다.

노드 풀 우선순위 규칙

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

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

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

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

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

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

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

우선순위 규칙의 기본값

ComputeClass 사양의 우선순위 규칙에 있는 일부 필드의 기본값을 설정할 수 있습니다. 이러한 기본값은 특정 규칙의 해당 필드가 생략된 경우에 적용됩니다. ComputeClass 사양의 priorityDefaults 필드를 사용하여 이러한 기본값을 설정할 수 있습니다.

priorityDefaults 필드에는 다음과 같은 제한사항이 있습니다.

  • GKE 버전 1.32.1-gke.1729000 이상이 필요합니다.
  • 필드가 포함되지 않은 nodepools 우선순위 규칙과 호환되지 않습니다.

설정할 수 있는 기본값 유형에 대한 자세한 내용은 ComputeClass CustomResourceDefinition의 priorityDefaults 섹션을 참고하세요.

GKE Standard 노드 풀 및 ComputeClass

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

ComputeClass 사용을 위해 수동으로 만든 노드 풀 구성

GKE Standard 클러스터에 수동으로 만든 노드 풀이 있는 경우 이러한 노드 풀을 특정 ComputeClass와 연결되도록 구성해야 합니다. GKE는 특정 ComputeClass를 요청하는 포드를 해당 ComputeClass와 연결된 노드 풀의 노드에만 예약합니다. 이 요구사항은 클러스터 수준 기본값으로 구성하는 ComputeClass에는 적용되지 않습니다.

GKE Autopilot 모드와 GKE Standard 모드의 자동 생성 노드 풀은 이 구성을 자동으로 수행합니다.

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

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

이러한 속성에서 COMPUTE_CLASS는 커스텀 ComputeClass의 이름입니다.

예를 들어 다음 명령어는 함께 기존 노드 풀을 업데이트하고 노드 풀을 dev-class ComputeClass와 연결합니다.

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

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

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

노드 풀 자동 생성 및 ComputeClasses

커스텀 ComputeClass와 함께 노드 풀 자동 생성을 사용하면 GKE가 우선순위 규칙에 따라 노드 풀을 자동으로 만들고 삭제하도록 할 수 있습니다.

GKE가 ComputeClass의 노드 풀을 자동으로 만들도록 하려면 다음을 실행해야 합니다.

  1. ComputeClass 사양에 enabled: true 값이 있는 nodePoolAutoCreation 필드를 추가합니다.
  2. 클러스터가 신속 채널에 등록되어 있고 GKE 버전 1.33.3-gke.1136000 이상을 실행하지 않는 한 클러스터 수준 노드 자동 프로비저닝을 사용 설정해야 합니다.

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

동일한 클러스터에서 수동으로 만든 노드 풀과 상호작용하는 ComputeClass와 함께 노드 풀 자동 생성을 사용 설정하는 ComputeClass를 사용할 수 있습니다.

노드 풀 자동 생성과의 다음 상호작용을 고려해 보세요.

  • 머신 계열 또는 스팟 VM 노드 선택기는 ComputeClass 동작과 충돌하므로 사용할 수 없습니다. GKE는 ComputeClass를 요청하면서 스팟 VM 또는 특정 머신 시리즈도 요청하는 모든 포드를 거부합니다.

  • 클러스터의 기본 ComputeClass를 설정하는 경우 머신 제품군 노드 선택기를 사용하는 포드는 다음 상황 중 하나에서 해당 기본 클래스의 노드 생성만 트리거합니다.

    • 포드는 클러스터 수준 기본 클래스의 우선순위 규칙 중 하나와 일치하는 머신 계열을 선택합니다. 예를 들어 N4 인스턴스를 선택하는 포드는 클러스터 수준 기본 클래스에 N4 인스턴스에 대한 우선순위 규칙이 있는 경우 노드 생성을 트리거합니다.
    • 클러스터 수준 기본 ComputeClass의 spec.whenUnsatisfiable 필드 값은 ScaleUpAnyway입니다. 포드가 ComputeClass 우선순위에 없는 머신 계열을 선택하더라도 GKE는 해당 머신 계열로 새 노드를 만듭니다.

    클러스터 수준 기본 클래스 우선순위에 없는 머신 계열을 선택하는 포드는 ComputeClass의 whenUnsatisfiable 필드에 DoNotScaleUp 값이 있는 경우 노드 생성을 트리거하지 않습니다.

  • nodepools 필드를 사용하여 기존 노드 풀을 참조하는 ComputeClass에 노드 풀 자동 생성을 구성할 수 있습니다. GKE는 우선순위를 순서대로 처리하고 포드를 배치하기 위해 기존 노드 풀을 수직 확장하려고 시도합니다.

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

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

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

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

ComputeClass 정의에서 특정 노드 풀 타겟팅

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

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

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

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

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

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

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

  • ScaleUpAnyway: 클러스터의 기본 머신 구성을 사용하는 새 노드를 만듭니다. 1.33 이전 버전의 GKE에서는 이 필드를 생략하면 이 동작이 기본 동작입니다.

    GKE는 다음 작업 중 하나를 수행합니다.

    • Autopilot 클러스터에서 GKE는 노드 머신 구성과 관계없이 새 노드 또는 기존 노드에 포드를 배치합니다.
    • 노드 풀 자동 생성을 사용하지 않는 Standard 클러스터에서 GKE는 지정된 ComputeClass와 일치하는 라벨과 taint를 정의하는 수동으로 만든 노드 풀을 수직 확장하려고 시도합니다.
    • 노드 풀 자동 생성을 사용하는 Standard 클러스터에서 GKE는 기본 E2 머신 시리즈를 사용하여 포드를 배치하는 새 노드 풀을 만들 수 있습니다.

  • DoNotScaleUp: ComputeClass 요구사항을 충족하는 노드를 사용할 수 있을 때까지 포드를 Pending 상태로 둡니다. GKE 버전 1.33 이상에서는 이 필드를 생략하면 이 동작이 기본 동작입니다.

배치 정책 요청

GKE 버전 1.33.2-gke.1335000부터 GKE Autopilot 클러스터에서 커스텀 배치 정책 또는 워크로드 정책을 사용하여 압축 배치를 사용할 수 있습니다. 자세한 내용은 압축 배치 정책과 워크로드 정책 비교를 참고하세요.

배치 정책과 워크로드 정책 모두 네트워크 지연 시간을 줄이기 위해 노드를 물리적으로 가까이 배치합니다. 특정 정책을 사용하려면 policyName 필드에 정책 이름을 제공합니다. 정책은 GKE 프로젝트에 이미 있는 Compute Engine 리소스 정책이어야 합니다.

다음 예시를 참조하세요.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

이 구성에서 GKE는 이 ComputeClass를 사용하는 모든 워크로드에 대해 컴팩트 배치 정책을 적용하고 my-placement-policy라는 기존 리소스 정책에 따라 노드를 프로비저닝합니다.

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

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

노드 삭제 시점과 기준은 자동 확장 프로필에 따라 다릅니다. 커스텀 ComputeClass 정의에서 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: n4
  - machineFamily: c4
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

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

활성 마이그레이션

활성 마이그레이션은 커스텀 ComputeClass의 선택적 자동 확장 기능으로, 기존 노드를 새 노드로 자동으로 대체합니다. 노드는 마이그레이션 유형에 따라 특정 기준에 따라 교체됩니다.

활성 마이그레이션이 발생하면 GKE는 새 노드를 만든 다음 더 이상 사용되지 않는 노드를 드레이닝하고 삭제합니다. 워크로드 중단을 최소화하기 위해 마이그레이션은 점진적으로 진행됩니다. 활성 마이그레이션에는 다음과 같은 고려사항이 있습니다.

  • 활성 마이그레이션은 Compute Engine 영구 디스크와 같은 영구 스토리지에 저장된 데이터를 마이그레이션하지 않습니다. 데이터 손실 위험을 최소화하려면 상태 저장 워크로드가 사용하는 ComputeClass에서 활성 마이그레이션을 사용 설정하지 마세요.
  • Standard 클러스터에서 노드 자동 프로비저닝을 사용 설정한 경우 기존 노드 풀이 커스텀 컴퓨팅 클래스에 정의된 기준을 충족하지 못하면 활성 마이그레이션에서 새 노드 풀 생성을 트리거할 수 있습니다.
  • 활성 마이그레이션은 삭제할 수 없는 노드를 대체하지 않습니다. 예를 들어 활성 마이그레이션은 --min-nodes 노드 풀 설정을 위반하는 경우 노드를 대체하지 않습니다.
  • 핵심 워크로드가 중단되지 않도록 활성 마이그레이션에서는 다음 포드를 이동하지 않습니다.
    • PodDisruptionBudget을 설정하며 이동으로 인해 PodDisruptionBudget이 초과되는 포드
    • cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 주석이 있는 포드
  • Hyperdisk와 같은 영역 리소스가 있는 영구 볼륨을 사용하는 워크로드는 활성 마이그레이션과 잘 작동하지 않을 수 있습니다. 일부 Hyperdisk 제품의 영역 제한 및 머신 유형 제한으로 인해 활성 마이그레이션의 효과가 감소할 수 있습니다. 또한 일부 상태 저장 워크로드는 활성 마이그레이션으로 인한 중단을 허용하지 않을 수 있습니다.
  • 활성 마이그레이션을 사용 설정하도록 기존 ComputeClass를 업데이트하면 GKE는 시간이 지남에 따라 기존 Pod를 새 노드로 마이그레이션합니다.

다음 유형의 활성 마이그레이션이 지원됩니다.

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

활성 마이그레이션을 구성하여 ComputeClass 대체 우선순위 목록에서 더 낮은 기존 노드를 해당 우선순위 목록에서 더 높은 새 노드로 대체할 수 있습니다. 이 구성을 사용하면 처음에는 GKE가 선호도가 낮은 노드에서 포드를 실행했더라도 실행 중인 모든 포드가 결국 해당 ComputeClass의 가장 선호되는 노드에서 실행됩니다.

다음 ComputeClass 사양 예시에서는 C4 노드보다 N4 노드를 우선시합니다.

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

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

예약할 수 없는 DaemonSet 포드를 실행하도록 활성 마이그레이션 구성

예약할 수 없는 DaemonSet 포드가 있는 기존 노드를 필요한 모든 DaemonSet 포드를 실행할 수 있는 더 큰 노드로 자동으로 대체하도록 활성 마이그레이션을 구성할 수 있습니다.

다음 ComputeClass 사양 예를 참고하세요.

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

예를 들어 이 ComputeClass로 포드를 배포하면 n1-standard-2 머신이 확장되고 나중에 CPU 2개를 요청하는 DaemonSet을 배포한 경우 활성 마이그레이션은 n1-standard-2 노드를 동일한 n1 머신 계열의 더 큰 노드(예: n1-standard-4)로 대체하여 모든 포드를 위한 충분한 공간을 만듭니다.

Compute Engine 예약 사용

GKE 버전 1.31.1-gke.2105000 이상에서 사용 가능

Compute Engine 용량 예약을 사용하여 특정Google Cloud 영역에서 하드웨어 가용성을 더 높은 수준으로 보장받는 경우, GKE가 새 노드를 만들 때 예약을 사용하도록 맞춤 ComputeClass에서 각 대체 우선순위를 구성할 수 있습니다.

커스텀 ComputeClass에서 예약을 사용하려면 다음 요구사항을 충족해야 합니다.

  • GKE가 예약을 사용하여 새 노드를 만들려면 노드 풀 자동 생성을 사용해야 합니다. 자세한 내용은 노드 풀 자동 생성 및 ComputeClasses 섹션을 참고하세요. 클러스터에서 노드 풀을 수동으로 만들 때 예약을 계속 사용할 수도 있습니다.
  • TPU가 아닌 예약은 machineType 또는 machineFamily가 정의된 경우에만 사용할 수 있습니다.
  • 로컬 SSD를 구성하는 ComputeClass는 machineFamily이 아닌 machineType 우선순위 규칙을 사용해야 합니다. 자세한 내용은 machineType 규칙 유형 섹션을 참고하세요.
  • 로컬 SSD가 연결된 machineType의 예약을 지정하는 ComputeClasses에는 localSSDCount: 필드가 명시적으로 포함되어야 합니다.

a3-highgpu-1g 인스턴스를 프로비저닝할 때 사용할 특정 공유 예약을 우선시하는 다음 ComputeClass 사양을 고려해 보세요. 우선순위가 지정된 인스턴스 유형을 사용할 수 없는 경우 GKE는 사양에 있는 일치하는 예약으로 대체합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

accelerator-reservations ComputeClass를 사용하는 포드를 배포하는 경우 GKE는 포드를 실행할 새 a3-highgpu-1g 인스턴스를 만들 때 먼저 a3-shared-reservation 예약을 사용하려고 시도합니다. 이 특정 예약에 사용 가능한 용량이 없으면 GKE는 일치하는 예약을 사용하여 a3-highgpu-1g 인스턴스를 확장하려고 시도합니다. 액세스할 수 있는 예약이 없으면 GKE는 a3-highgpu-1g 스팟 VM으로 대체됩니다. 마지막으로 Spot VM을 사용할 수 없으면 확장 작업이 실패합니다.

이 예시에서 예약 참조가 있는 두 우선순위 규칙 모두 localSSDCount: 필드가 필요합니다. a3-highgpu-1g 머신 셰이프에 로컬 SSD가 포함되어 있기 때문입니다.

다음 예에서는 스팟 VM으로 대체된 후 최종적으로 온디맨드 VM으로 대체되는 공유 특정 예약을 보여줍니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

다음 유형의 예약을 사용할 수 있습니다.

  • 특정 단일 프로젝트 예약: 다음 필드를 구성합니다.

    • reservations.specific.name: 예약 이름입니다.
    • reservations.affinity: Specific이어야 합니다.

  • 특정 공유 예약: 다음 필드를 구성합니다.

    • reservations.specific.name: 예약 이름입니다.
    • reservations.specific.project: 예약을 소유한 프로젝트의 프로젝트 ID입니다.
    • reservations.affinity: Specific이어야 합니다.

  • 일치하는 예약: 다음 필드를 구성합니다.

    • reservations.affinity: AnyBestEffort이어야 합니다.
    • 예약 이름이나 프로젝트를 설정하지 마세요.

TPU 예약에는 특정 어피니티가 필요합니다. reservations.affinity: AnyBestEffort는 지원되지 않습니다.

GKE가 예약에서 사용 가능한 용량을 찾을 수 없는 경우 결과 동작은 ComputeClass 우선순위 규칙에서 선택된 예약 유형에 따라 다음과 같이 달라집니다.

  • 특정 예약: GKE가 ComputeClass의 다음 우선순위 규칙을 시도합니다.
  • 일치하는 예약: GKE는 해당 우선순위 규칙의 요구사항을 충족하는 주문형 노드를 프로비저닝하려고 시도합니다. GKE가 온디맨드 노드를 프로비저닝할 수 없는 경우 GKE는 ComputeClass의 다음 우선순위 규칙을 시도합니다.

GKE가 ComputeClass의 우선순위 규칙 요구사항을 충족할 수 없는 경우 규칙이 적용되지 않는 경우의 동작이 발생합니다.

특정 예약 블록 사용

GKE 버전 1.31.4-gke.1072000부터 하드웨어 지원 예약 내에서 특정 예약 블록을 타겟팅할 수 있습니다. 이 기능은 A3 Ultra 및 A4 머신 유형에서 사용할 수 있습니다.

특정 예약 블록을 사용하려면 이 예와 같이 ComputeClass 리소스를 구성하세요.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

RESERVATION_BLOCK_NAME을 대상 예약 블록 이름으로 바꿉니다.

GKE 버전 1.33.1-gke.1788000부터 예약 블록 내의 특정 예약 하위 블록을 타겟팅할 수 있습니다. 이 기능은 A4X 머신 유형에서 사용할 수 있습니다.

특정 예약 하위 블록을 사용하려면 특정 예약 하위 블록 사용의 예와 같이 ComputeClass 리소스를 구성합니다.

이 기능을 사용할 때는 다음 사항을 고려하세요.

  • 이러한 기능은 단일 프로젝트 또는 공유 프로젝트의 특정 예약에만 적용됩니다.

노드 시스템 구성 맞춤설정

ComputeClass 사양에서 nodeSystemConfig 필드를 사용하여 kubelet 및 Linux 커널의 특정 매개변수를 맞춤설정할 수 있습니다. Compute Engine 머신 시리즈 또는 머신 유형을 정의하는 우선순위 규칙에서 이 필드를 지정할 수 있습니다. ComputeClass에서 priorityDefaults 필드에 nodeSystemConfig 필드를 추가하여 우선순위 규칙에서 생략된 노드 시스템 구성 필드의 기본 전역 값을 설정할 수도 있습니다.

이 기능은 GKE 버전 1.32.1-gke.1729000 이상에서 사용할 수 있습니다.

자세한 내용은 다음 페이지를 참조하세요.

클러스터 및 네임스페이스의 기본 ComputeClasses

특정 ComputeClass를 선택하지 않는 포드에 기본적으로 ComputeClass를 적용하도록 GKE를 구성할 수 있습니다. 특정 네임스페이스 또는 전체 클러스터의 기본 ComputeClass를 정의할 수 있습니다. 기본 클래스로 클러스터 또는 네임스페이스를 구성하는 방법에 관한 자세한 내용은 기본적으로 ComputeClass를 포드에 적용을 참고하세요.

노드 풀 그룹화

GKE 버전 1.32.2-gke.1359000부터 ComputeClass 사양의 nodePoolGroup 필드를 사용하여 여러 노드 풀을 컬렉션이라는 단일 논리 단위로 그룹화할 수 있습니다. 이 그룹화를 사용하면 여러 노드 풀에 공유 구성을 적용할 수 있습니다.

TPU 멀티 호스트 수집

TPU 멀티 호스트 배포를 그룹화하여 컬렉션 내의 모든 노드 풀에 서비스 수준 목표(SLO)를 설정할 수 있습니다. 노드 풀을 그룹화하려면 nodePoolGroup 필드에 그룹 이름을 지정합니다. 이 ComputeClass를 사용하여 프로비저닝된 모든 노드 풀은 동일한 그룹에 속합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

자세한 내용은 다음을 참조하세요.

노드 풀 구성

ComputeClass 사양의 nodePoolConfig 필드를 사용하면 해당 클래스를 사용하여 만든 노드 풀 내의 모든 노드에 반영되는 구성을 적용할 수 있습니다.

이미지 유형 지정

imageType 필드를 사용하여 노드 풀의 노드에 대한 기본 운영체제를 지정할 수 있습니다. 이 필드를 사용하면 노드에서 실행될 노드 풀의 이미지 유형을 선택할 수 있습니다. 이 필드를 생략하면 기본값은 cos_containerd입니다. 다음 예에서는 ComputeClass에서 imageType를 지정하는 방법을 보여줍니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

자세한 내용은 노드 이미지를 참고하세요.

서비스 계정

serviceAccount 필드는 ComputeClass에서 관리하는 노드 풀 내의 노드에서 사용하는 Google Cloud 서비스 계정을 지정합니다. 다음 예에서는 ComputeClass에서 serviceAccount를 지정하는 방법을 보여줍니다.

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

자세한 내용은 GKE의 서비스 계정 정보를 참고하세요.

TPU SLO의 워크로드 유형 정의

GKE 버전 1.32.2-gke.1359000부터 nodePoolConfig 내에서 workloadType 필드를 사용하여 TPU 워크로드의 서비스 수준 목표 (SLO)를 정의할 수 있습니다. 이 필드의 값은 GKE에 TPU 리소스의 용도를 알려줍니다. workloadType 필드는 다음 값을 지원합니다.

  • HIGH_AVAILABILITY: 추론 제공과 같은 가용성 중심 워크로드에 이 값을 사용하여 중단을 제한하고 간소화합니다.
  • HIGH_THROUGHPUT: 기본 인프라가 대부분의 시간 동안 실행되어야 진행되는 일괄 또는 학습 작업에 이 값을 사용합니다. 이 값은 nodePoolGroup도 지정된 경우에만 사용할 수 있습니다.

다음 예에서는 고가용성 추론 워크로드에 최적화된 멀티 호스트 TPU 컬렉션의 ComputeClass를 정의합니다.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

자세한 내용은 다음 페이지를 참조하세요.

워크로드에서 ComputeClasses 요청

커스텀 ComputeClass를 사용하려면 포드 사양에서 nodeSelector를 사용하여 해당 ComputeClass를 명시적으로 요청해야 합니다. 원하는 경우 특정 Kubernetes 네임스페이스의 기본값으로 ComputeClass를 설정할 수 있습니다. 해당 네임스페이스의 포드는 포드가 다른 ComputeClass를 요청하지 않는 한 해당 ComputeClass를 사용합니다.

예를 들어 다음 매니페스트는 cost-optimized ComputeClass를 요청합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

시스템 노드 라벨의 노드 선택기

GKE는 머신 유형, 연결된 하드웨어 가속기, 부팅 디스크 유형과 같은 기준으로 노드를 식별하기 위해 노드에 시스템 라벨을 추가합니다. 이러한 시스템 라벨의 라벨 키에는 다음 접두사 중 하나가 있습니다.

  • k8s.io
  • cloud.google.com
  • gke.io

GKE 버전 1.32.3-gke.1499000 이상에서는 노드 선택기를 사용하여 시스템 라벨과 ComputeClass를 동시에 선택하는 워크로드를 배포할 수 있습니다. ComputeClasses를 선택하는 포드에서 시스템 라벨을 선택하는 경우 해당 포드가 예상대로 예약되는지 확인합니다. ComputeClass 구성과 포드의 노드 선택기 간의 충돌로 인해 다음과 같은 문제가 발생할 수 있습니다.

  • GKE는 ComputeClass의 우선순위가 가장 높은 구성을 사용하는 노드를 만들 수 없습니다.
  • 포드가 Pending 상태로 유지됩니다.

또한 GKE는 ComputeClass 사양에 해당 필드가 있는 시스템 라벨을 선택하는 포드도 거부합니다. ComputeClasses를 사용하는 경우 워크로드를 업데이트하여 노드 선택기에서 다음 라벨을 삭제하고 생성하는 ComputeClasses에서 해당 필드를 구성합니다.

노드 라벨 ComputeClass 필드
cloud.google.com/machine-family priorities.machineFamily
cloud.google.com/machine-type priorities.machineType
cloud.google.com/gke-spot priorities.spot
cloud.google.com/gke-accelerator priorities.gpu.type
cloud.google.com/gke-gpu-driver-version priorities.gpu.driverVersion
cloud.google.com/reservation-name priorities.reservations.specific.name
cloud.google.com/reservation-project priorities.reservations.specific.project
cloud.google.com/reservation-affinity priorities.reservations.affinity
cloud.google.com/gke-ephemeral-storage-local-ssd priorities.storage.localSSDCount
cloud.google.com/gke-boot-disk priorities.storage.bootDiskType
cloud.google.com/gke-boot-disk-size priorities.storage.bootDiskSize
cloud.google.com/gke-node-pool-group-name nodePoolGroup.name
cloud.google.com/gke-workload-type nodePoolConfig.workloadType

제한사항

ComputeClass의 이름은 gke 또는 autopilot로 시작할 수 없습니다.

다음 단계