Cluster Toolkit으로 AI 최적화 GKE 클러스터 만들기

이 문서에서는 A4X, A4, A3 Ultra, A3 Mega, A3 High (8 GPU) Compute Engine 인스턴스를 사용하여 AI 및 ML 워크로드를 지원하는 AI 최적화 Google Kubernetes Engine (GKE) 클러스터를 만드는 방법을 보여줍니다.

A4X, A4, A3 Ultra, A3 Mega, A3 High (GPU 8개) 머신 시리즈는 대규모 AI/ML 클러스터를 실행할 수 있도록 설계되었으며, 워크로드 배치 지정, 고급 클러스터 유지보수 제어, 토폴로지 인식 스케줄링과 같은 기능을 제공합니다. 자세한 내용은 클러스터 관리 개요를 참조하세요.

GKE는 조직의 요구사항에 맞게 다양한 워크로드를 실행할 수 있는 단일 플랫폼 표면을 제공합니다. 이러한 워크로드에는 고성능 분산 사전 학습, 모델 미세 조정, 모델 추론, 애플리케이션 서빙, 지원 서비스가 포함됩니다. GKE는 여러 플랫폼을 관리하는 운영 부담을 줄여줍니다.

AI 최적화 GKE 클러스터를 만드는 방법 선택

클러스터 생성을 위한 다음 옵션은 각각 클러스터 구성 및 워크로드 예약에서 다양한 수준의 편의성과 유연성을 제공합니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
    • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
  • GKE 클러스터 및 연결된 서비스 계정을 만들고 관리하는 데 필요한 권한이 있는지 확인합니다.
    • Kubernetes Engine 관리자(roles/container.admin)
    • Compute 관리자(roles/compute.admin)
    • 스토리지 관리자(roles/storage.admin)
    • 프로젝트 IAM 관리자(roles/resourcemanager.projectIamAdmin)
    • 서비스 계정 관리자(roles/iam.serviceAccountAdmin)
    • 서비스 계정 사용자(roles/iam.serviceAccountUser)
    • 서비스 사용량 소비자(roles/serviceusage.serviceUsageConsumer)
    • 역할 관리자 (roles/iam.roleAdmin)
    • Secret Manager 보안 비밀 버전 관리자 (roles/secretmanager.secretVersionManager)
    • 단일 프로젝트 예약 사용: 프로젝트에 대한 Compute 인스턴스 관리자 (v1) (roles/compute.instanceAdmin.v1)
    • 공유 예약 사용: 소유자 프로젝트와 예약을 사용하려는 소비자 프로젝트 모두에 대한 Compute 인스턴스 관리자 (v1) (roles/compute.instanceAdmin.v1)

소비 옵션 선택 및 용량 확보

용량을 확보하려면 다음 단계를 완료하세요.

  1. 소비 옵션 선택: GPU 리소스를 가져오고 사용하는 방법에 따라 선택합니다. 자세한 내용은 사용 옵션 선택을 참조하세요.

    GKE의 경우 소비 옵션을 선택할 때 다음 추가 정보를 고려하세요.

  2. 용량 확보: 용량을 확보하는 프로세스는 소비 옵션마다 다릅니다. 선택한 소비 옵션의 프로세스에 대해 알아보려면 용량 개요를 참조하세요.

요구사항

AI 최적화 GKE 클러스터에는 다음 요구사항이 적용됩니다.

  • A4X Max의 경우 다음 버전 중 하나를 사용해야 합니다.

    • 1.35 이상의 경우 GKE 버전 1.35.0-gke.2745000 이상을 사용합니다.
    • 1.34의 경우 GKE 버전 1.34.3-gke.1318000 이상을 사용합니다.

    이러한 버전은 A4X Max가 다음을 사용하도록 보장합니다.

    • A4X Max의 최소 GPU 드라이버 버전인 R580.95.05는 기본적으로 사용 설정되어 있습니다.
    • 일관된 드라이버 기반 메모리 관리 (CDMM)는 기본적으로 사용 설정되어 있습니다. NVIDIA는 Kubernetes 클러스터에서 이 모드를 사용 설정하여 메모리 과다 보고를 해결할 것을 권장합니다. CDMM을 사용하면 운영체제 (OS) 대신 드라이버를 통해 GPU 메모리를 관리할 수 있습니다. 이 접근 방식은 GPU 메모리의 OS 온라인화를 방지하고 GPU 메모리를 비균일 메모리 액세스 (NUMA) 노드로 OS에 노출하는 데 도움이 됩니다. CDMM이 사용 설정된 경우 멀티 인스턴스 GPU는 지원되지 않습니다. CDMM에 관한 자세한 내용은 하드웨어 및 소프트웨어 지원을 참고하세요.
    • GPUDirect RDMA 및 MNNVL: A4X Max 노드 풀에서 A4X Max의 네트워킹 기능을 사용할 수 있도록 설정하는 것이 좋습니다.

  • A4X의 경우 다음 버전 중 하나를 사용해야 합니다.

    • 1.33 이상의 경우 GKE 버전 1.33.4-gke.1036000 이상을 사용합니다.
    • 1.32의 경우 GKE 버전 1.32.8-gke.1108000 이상을 사용합니다.

    이러한 버전은 A4X에서 다음을 사용하도록 보장합니다.

    • A4X의 최소 GPU 드라이버 버전인 R580은 기본적으로 사용 설정되어 있습니다.
    • 일관된 드라이버 기반 메모리 관리 (CDMM)는 기본적으로 사용 설정되어 있습니다. NVIDIA는 Kubernetes 클러스터에서 이 모드를 사용 설정하여 메모리 과다 보고를 해결할 것을 권장합니다. CDMM을 사용하면 운영체제 (OS) 대신 드라이버를 통해 GPU 메모리를 관리할 수 있습니다. 이 접근 방식은 GPU 메모리의 OS 온라인화를 방지하고 GPU 메모리를 비균일 메모리 액세스 (NUMA) 노드로 OS에 노출하는 데 도움이 됩니다. CDMM이 사용 설정된 경우 멀티 인스턴스 GPU는 지원되지 않습니다. CDMM에 관한 자세한 내용은 하드웨어 및 소프트웨어 지원을 참고하세요.
    • GPUDirect RDMA 및 MNNVL: A4X 노드 풀에서 A4X의 네트워킹 기능을 사용할 수 있도록 하는 데 권장됩니다.

  • 머신 유형에 따라 최소 GPU 드라이버 버전을 사용해야 합니다.

    • A4X Max: A4X Max 베어메탈 인스턴스의 GB300 GPU에는 최소 R580.95.05 GPU 드라이버 버전이 필요합니다. 앞서 언급한 버전 요구사항을 참고하세요.
    • A4X: A4X 인스턴스의 GB200 GPU에는 최소 R580 GPU 드라이버 버전이 필요합니다. 앞서 언급한 버전 요구사항을 참고하세요.
    • A4: A4 인스턴스의 B200 GPU에는 최소 R570 GPU 드라이버 버전이 필요합니다. GKE는 기본적으로 A4에 필요한 최소 버전인 1.32.1-gke.1729000 이상을 실행하는 모든 A4 노드에 이 드라이버 버전을 자동으로 설치합니다.
    • A3 Ultra: A3 Ultra 인스턴스의 H200 GPU에는 최소 R550 GPU 드라이버 버전이 필요하며, 이는 GKE 1.31에서 latest 드라이버 버전으로 제공됩니다. A3 Ultra의 경우 GKE 1.31에서 gpu-driver-version=latest를 설정해야 합니다. GKE 버전 1.31.5-gke.1169000 이상에서 GKE는 기본적으로 A3 Ultra 노드에 R550 GPU 드라이버 버전을 자동으로 설치합니다.
    • A3 Mega 및 A3 High: A3 High 및 A3 Mega 인스턴스의 H100 GPU는 지원되는 모든 GKE 버전의 기본 GPU 드라이버 버전에서 지원됩니다. gpu-driver-version=latest을 설정하여 지원되는 GKE 버전에서 사용할 수 있는 최신 프로덕션 드라이버에 액세스할 수도 있습니다.

  • A3 Ultra 노드 풀의 경우 디스크 유형을 hyperdisk-balanced로 설정해야 합니다.

  • GPUDirect RDMA를 사용하려면 머신 유형에 따라 다음 최소 버전을 사용합니다.

    • A4X Max: 이전에 언급된 버전 요구사항을 참조하세요.
    • A4X: 이전에 언급된 버전 요구사항을 참조하세요.
    • A4: 1.32.2-gke.1475000 이상을 사용합니다.
    • A3 Ultra: 1.31.4-gke.1183000 이상을 사용합니다.

  • GPUDirect-TCPXO (A3 Mega용) 및 GPUDirect-TCPX (A3 High용)를 사용하려면 다음 GKE 버전을 사용합니다.

    • A3 High: 1.34 이전의 사용 가능한 GKE 버전을 사용합니다.
    • A3 Mega: 사용 가능한 GKE 버전을 사용합니다.

  • GPUDirect RDMA를 사용하려면 GKE 노드가 Container-Optimized OS 노드 이미지를 사용해야 합니다. Ubuntu 및 Windows 노드 이미지는 지원되지 않습니다.

  • A4X Max 및 A4X로 클러스터를 만들려면 예약에 따름 프로비저닝 모델을 사용해야 합니다. 다른 프로비저닝 모델은 지원되지 않습니다.

Cluster Toolkit으로 클러스터 만들기

다음 안내에 따라 Cluster Toolkit을 사용하여 클러스터를 만듭니다. 이 섹션에서는 클러스터 생성 프로세스를 안내하여 프로젝트가 권장사항을 따르고 AI 최적화 GKE 클러스터의 요구사항을 충족하는지 확인합니다. 이 섹션에서는 또한 Terraform을 사용하여 배포를 위한 인프라를 프로비저닝하고 관리하는 방법을 보여줍니다.

A4X Max

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수 있지만 Cluster Toolkit에 대한 종속 항목이 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 종속 항목 설치 안내에 따라 다른 환경을 준비합니다.

  2. Cluster Toolkit을 설치합니다.

  3. Terraform 배포 상태를 저장하기 위해 버전 관리가 사용 설정된 Cloud Storage 버킷을 만듭니다.

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름으로, 버킷 이름 지정 요구사항을 충족해야 합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포 상태를 저장할 컴퓨팅 리전입니다.

  4. GitHub 저장소의 examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml 청사진에서 terraform_backend_defaults 및 vars 섹션의 다음 설정을 배포의 특정 값과 일치하도록 작성합니다.

    • BUCKET: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • DEPLOYMENT_NAME: 배포의 고유한 이름으로, 길이는 6~30자(영문 기준)여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a4x-max-bm입니다.
    • REGION: 클러스터의 컴퓨팅 리전입니다.
    • ZONE: A4X Max 머신의 노드 풀에 대한 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • STATIC_NODE_COUNT: 클러스터 노드 풀의 A4X Max 노드 수입니다. 18개 이하여야 합니다. NVLink 도메인을 사용하여 하나의 하위 블록에서 1x72의 GPU 토폴로지를 가져오려면 노드 18개를 사용하는 것이 좋습니다.
    • AUTHORIZED_CIDR: 클러스터에 연결할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방법을 참조하세요.

    • reservation 필드의 경우 노드 풀을 프로비저닝할 때 예약에서 특정 블록을 타겟팅할지 여부에 따라 다음 중 하나를 사용합니다.

    • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름(RESERVATION_NAME)을 제공합니다.

    • 예약 내의 특정 블록을 타겟팅하려면 다음 형식의 예약 및 블록 이름을 사용합니다.

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      예약에서 사용할 수 있는 블록을 모르는 경우 예약 토폴로지 보기를 참조하세요.

    • RESERVATION_PROJECT_ID: 예약이 있는 Google Cloud프로젝트 ID입니다. 예약이 PROJECT_ID과 다른 프로젝트에 있을 수 있습니다.

    • NUM_NODE_POOLS: 클러스터에서 사용 설정할 노드 풀 수입니다. 노드가 18개보다 큰 클러스터를 원하는 경우 노드 풀을 여러 개 지정할 수 있습니다. 기본값은 1입니다.

    고급 설정을 수정하려면 examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml 청사진 파일을 수정합니다.

  5. 애플리케이션 기본 사용자 인증 정보 (ADC)를 생성하여 Terraform에 대한 액세스 권한을 제공합니다. Cloud Shell을 사용하는 경우 gcloud auth application-default login 명령어를 사용합니다.

    gcloud auth application-default login

  6. gcluster deploy 명령어를 사용하여 청사진을 배포하고 A4X Max 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml \
    examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml

  7. 메시지가 표시되면 (A)pply를 선택하여 청사진을 배포합니다.

    • 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
    • 청사진에서 fio-bench-job-template 작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.

A4X

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수 있지만 Cluster Toolkit에 대한 종속 항목이 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 종속 항목 설치 안내에 따라 다른 환경을 준비합니다.

  2. Cluster Toolkit을 설치합니다.

  3. Terraform 배포 상태를 저장하기 위해 버전 관리가 사용 설정된 Cloud Storage 버킷을 만듭니다.

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름으로, 버킷 이름 지정 요구사항을 충족해야 합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포 상태를 저장할 컴퓨팅 리전입니다.

  4. GitHub 저장소의 examples/gke-a4x/gke-a4x-deployment.yaml 청사진에서 terraform_backend_defaults 및 vars 섹션에 다음 설정을 입력하여 배포의 특정 값과 일치시킵니다.

    • BUCKET: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • DEPLOYMENT_NAME: 배포의 고유한 이름으로, 길이는 6~30자(영문 기준)여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a4x입니다.
    • REGION: 클러스터의 컴퓨팅 리전입니다.
    • ZONE: A4X 머신 노드 풀의 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • STATIC_NODE_COUNT: 클러스터 노드 풀의 A4X 노드 수입니다. 18개 이하여야 합니다. NVLink 도메인을 사용하여 한 하위 블록에서 1x72의 GPU 토폴로지를 가져오려면 노드 18개를 사용하는 것이 좋습니다.
    • AUTHORIZED_CIDR: 클러스터에 연결할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방법을 참조하세요.

    • reservation 필드의 경우 노드 풀을 프로비저닝할 때 예약에서 특정 블록을 타겟팅할지 여부에 따라 다음 중 하나를 사용합니다.

    • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름(RESERVATION_NAME)을 제공합니다.

    • 예약 내의 특정 블록을 타겟팅하려면 다음 형식의 예약 및 블록 이름을 사용합니다.

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      예약에서 사용할 수 있는 블록을 모르는 경우 예약 토폴로지 보기를 참조하세요.

    • RESERVATION_PROJECT_ID: 예약이 있는 Google Cloud프로젝트 ID입니다. 예약이 PROJECT_ID과 다른 프로젝트에 있을 수 있습니다.

    • NUM_NODE_POOLS: 클러스터에서 사용 설정할 노드 풀 수입니다. 노드가 18개보다 큰 클러스터를 원하는 경우 노드 풀을 여러 개 지정할 수 있습니다. 기본값은 1입니다.

    고급 설정을 수정하려면 examples/gke-a4x/gke-a4x.yaml 청사진 파일을 수정합니다.

  5. 애플리케이션 기본 사용자 인증 정보 (ADC)를 생성하여 Terraform에 대한 액세스 권한을 제공합니다. Cloud Shell을 사용하는 경우 gcloud auth application-default login 명령어를 사용합니다.

    gcloud auth application-default login

  6. gcluster deploy 명령어를 사용하여 청사진을 배포하고 A4X 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml

  7. 메시지가 표시되면 (A)pply를 선택하여 청사진을 배포합니다.

    • 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
    • 청사진에서 fio-bench-job-template 작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.

A4

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수 있지만 Cluster Toolkit에 대한 종속 항목이 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 종속 항목 설치 안내에 따라 다른 환경을 준비합니다.

  2. Cluster Toolkit을 설치합니다.

  3. Terraform 배포 상태를 저장하기 위해 버전 관리가 사용 설정된 Cloud Storage 버킷을 만듭니다.

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름으로, 버킷 이름 지정 요구사항을 충족해야 합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포 상태를 저장할 컴퓨팅 리전입니다.

  4. GKE 배포의 소비 옵션을 선택합니다.

    기본적으로 배포 파일은 특정 예약을 사용하도록 구성됩니다. 대체 가격 모델 (예: 스팟 VM 또는 flex-start 프로비저닝 모드)을 사용하려면 배포 YAML 파일을 업데이트합니다. 자세한 내용은 GKE 사용 옵션을 참조하세요.

  5. GitHub 저장소의 examples/gke-a4/gke-a4-deployment.yaml 청사진에서 terraform_backend_defaults 및 vars 섹션에 다음 설정을 입력하여 배포의 특정 값과 일치시킵니다.

    • BUCKET: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • DEPLOYMENT_NAME: 배포의 고유한 이름으로, 길이는 6~30자(영문 기준)여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a4입니다.
    • REGION: 클러스터의 컴퓨팅 리전입니다.
    • ZONE: A4 머신의 노드 풀에 대한 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • AUTHORIZED_CIDR: 클러스터에 연결할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방법을 참조하세요.
    • 특정 예약 섹션에서 다음 설정을 구성합니다.

    • reservation_affinity 블록의 specific_reservations 목록에서 예약 name 필드를 지정합니다.

      • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름 (RESERVATION_NAME)을 제공합니다.
      • 예약 내의 특정 블록을 타겟팅하려면 다음 형식의 예약 및 블록 이름을 사용합니다.
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      예약에서 사용할 수 있는 블록을 모르는 경우 예약 토폴로지 보기를 참조하세요.

    • STATIC_NODE_COUNT: 클러스터의 A4 노드 수입니다.

    고급 설정을 수정하려면 examples/gke-a4/gke-a4.yaml 청사진 파일을 수정합니다.

  6. 애플리케이션 기본 사용자 인증 정보 (ADC)를 생성하여 Terraform에 대한 액세스 권한을 제공합니다. Cloud Shell을 사용하는 경우 gcloud auth application-default login 명령어를 사용합니다.

    gcloud auth application-default login

  7. gcluster deploy 명령어를 사용하여 청사진을 배포하고 A4 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml

  8. 메시지가 표시되면 (A)pply를 선택하여 청사진을 배포합니다.

    • 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
    • 청사진에서 fio-bench-job-template 작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.

A3 Ultra

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수 있지만 Cluster Toolkit에 대한 종속 항목이 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 종속 항목 설치 안내에 따라 다른 환경을 준비합니다.

  2. Cluster Toolkit을 설치합니다.

  3. Terraform 배포 상태를 저장하기 위해 버전 관리가 사용 설정된 Cloud Storage 버킷을 만듭니다.

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름으로, 버킷 이름 지정 요구사항을 충족해야 합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포 상태를 저장할 컴퓨팅 리전입니다.

  4. GKE 배포의 소비 옵션을 선택합니다.

    기본적으로 배포 파일은 특정 예약을 사용하도록 구성됩니다. 대체 가격 모델 (예: 스팟 VM 또는 flex-start 프로비저닝 모드)을 사용하려면 배포 YAML 파일을 업데이트합니다. 자세한 내용은 GKE 사용 옵션을 참조하세요.

  5. GitHub 저장소의 examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml 청사진에서 terraform_backend_defaults 및 vars 섹션에 다음 설정을 입력하여 배포의 특정 값과 일치시킵니다.

    • BUCKET: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • DEPLOYMENT_NAME: 배포의 고유한 이름으로, 길이는 6~30자(영문 기준)여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a3-ultragpu입니다.
    • REGION: 클러스터의 컴퓨팅 리전입니다.
    • ZONE: A3 Ultra 머신 노드 풀의 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • AUTHORIZED_CIDR: 클러스터에 연결할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방법을 참조하세요.
    • 특정 예약 섹션에서 다음 설정을 구성합니다.

    • reservation_affinity 블록의 specific_reservations 목록에서 예약 name 필드를 지정합니다.

      • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름 (RESERVATION_NAME)을 제공합니다.
      • 예약 내의 특정 블록을 타겟팅하려면 다음 형식의 예약 및 블록 이름을 사용합니다.
      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      예약에서 사용할 수 있는 블록을 모르는 경우 예약 토폴로지 보기를 참조하세요.

    • STATIC_NODE_COUNT: 클러스터의 A3 Ultra 노드 수입니다.

    고급 설정을 수정하려면 examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml 청사진 파일을 수정합니다.

  6. 애플리케이션 기본 사용자 인증 정보(ADC)를 생성하여 Terraform에 대한 액세스 권한을 제공합니다. Cloud Shell을 사용하는 경우 gcloud auth application-default login 명령어를 사용합니다.

    gcloud auth application-default login

  7. gcluster deploy 명령어를 사용하여 청사진을 배포하고 A3 Ultra 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  8. 메시지가 표시되면 (A)pply를 선택하여 청사진을 배포합니다.

    • 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
    • 청사진에서 fio-bench-job-template 작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.

A3 Mega

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수 있지만 Cluster Toolkit에 대한 종속 항목이 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 종속 항목 설치 안내에 따라 다른 환경을 준비합니다.

  2. Cluster Toolkit을 설치합니다.

  3. Terraform 배포 상태를 저장하기 위해 버전 관리가 사용 설정된 Cloud Storage 버킷을 만듭니다.

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름으로, 버킷 이름 지정 요구사항을 충족해야 합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포 상태를 저장할 컴퓨팅 리전입니다.

  4. GitHub 저장소의 examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml 청사진에서 terraform_backend_defaults 및 vars 섹션의 다음 변수를 배포의 특정 값과 일치하도록 바꿉니다.

    • BUCKET: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • DEPLOYMENT_NAME: 배포의 고유한 이름으로, 길이는 6~30자(영문 기준)여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • REGION: 클러스터의 컴퓨팅 리전입니다.
    • ZONE: A3 Mega 머신의 노드 풀에 대한 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • AUTHORIZED_CIDR: 클러스터에 연결할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방법을 참조하세요. 호스트 머신의 IP 주소를 가져오려면 curl -s https://ifconfig.me 명령어를 실행합니다.

  5. GKE 배포의 소비 옵션을 선택합니다.

    기본적으로 배포 파일은 표준 또는 미래용 예약을 사용하도록 구성됩니다. 대체 소비 모델 (예: 주문형 용량, 스팟 VM, flex-start 프로비저닝 모드)을 사용하려면 배포 YAML 파일을 업데이트합니다. 자세한 내용은 GKE 사용 옵션을 참조하세요.

    예약을 구성하려면 특정 예약 섹션에서 다음 값을 설정합니다.

    • reservation_affinity 블록의 specific_reservations 목록에서 예약 name 필드를 지정합니다.
    • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름 (RESERVATION_NAME)을 제공합니다.

    • 예약 내의 특정 블록을 타겟팅하려면 다음 형식의 예약 및 블록 이름을 사용합니다.

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      예약에서 사용할 수 있는 블록을 모르는 경우 예약 토폴로지 보기를 참조하세요.

    • STATIC_NODE_COUNT: 클러스터의 A3 Mega 노드 수

    고급 설정을 수정하려면 GitHub 저장소에서 examples/gke-a3-megagpu/gke-a3-megagpu.yaml 청사진을 수정합니다.

  6. 애플리케이션 기본 사용자 인증 정보(ADC)를 생성하여 Terraform에 대한 액세스 권한을 제공합니다. Cloud Shell을 사용하는 경우 gcloud auth application-default login 명령어를 사용합니다.

    gcloud auth application-default login

  7. gcluster deploy 명령어를 사용하여 청사진을 배포하고 A3 Mega 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml \
    examples/gke-a3-megagpu/gke-a3-megagpu.yaml

  8. 메시지가 표시되면 (A)pply를 선택하여 청사진을 배포합니다. 청사진은 VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.

A3 High

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수 있지만 Cluster Toolkit에 대한 종속 항목이 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 종속 항목 설치 안내에 따라 다른 환경을 준비합니다.

  2. Cluster Toolkit을 설치합니다.

  3. Terraform 배포 상태를 저장하기 위해 버전 관리가 사용 설정된 Cloud Storage 버킷을 만듭니다.

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름으로, 버킷 이름 지정 요구사항을 충족해야 합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포 상태를 저장할 컴퓨팅 리전입니다.

  4. GitHub 저장소의 examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml 청사진에서 terraform_backend_defaults 및 vars 섹션의 다음 변수를 배포의 특정 값과 일치하도록 바꿉니다.

    • BUCKET: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • DEPLOYMENT_NAME: 배포의 고유한 이름으로, 길이는 6~30자(영문 기준)여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • REGION: 클러스터의 컴퓨팅 리전입니다.
    • ZONE: A3 High 머신의 노드 풀에 대한 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • AUTHORIZED_CIDR: 클러스터에 연결할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방법을 참조하세요. 호스트 머신의 IP 주소를 가져오려면 curl -s https://ifconfig.me 명령어를 실행합니다.

  5. GKE 배포의 소비 옵션을 선택합니다.

    기본적으로 배포 파일은 표준 또는 미래용 예약을 사용하도록 구성됩니다. 대체 가격 모델 (예: 주문형 용량, 스팟 VM, flex-start 프로비저닝 모드)을 사용하려면 배포 YAML 파일을 업데이트합니다. 자세한 내용은 GKE 사용 옵션을 참조하세요.

    예약을 구성하려면 특정 예약 섹션에서 다음 값을 설정합니다.

    • reservation_affinity 블록의 specific_reservations 목록에서 예약 name 필드를 지정합니다.
    • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름 (RESERVATION_NAME)을 제공합니다.

    • 예약 내의 특정 블록을 타겟팅하려면 다음 형식의 예약 및 블록 이름을 사용합니다.

      RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      예약에서 사용할 수 있는 블록을 모르는 경우 예약 토폴로지 보기를 참조하세요.

    • STATIC_NODE_COUNT: 클러스터의 A3 High 노드 수입니다.

    고급 설정을 수정하려면 GitHub 저장소에서 examples/gke-a3-highgpu/gke-a3-highgpu.yaml 청사진을 수정합니다.

  6. 애플리케이션 기본 사용자 인증 정보(ADC)를 생성하여 Terraform에 대한 액세스 권한을 제공합니다. Cloud Shell을 사용하는 경우 gcloud auth application-default login 명령어를 사용합니다.

    gcloud auth application-default login

  7. gcluster deploy 명령어를 사용하여 청사진을 배포하고 A3 High 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
./gcluster deploy -d \
    examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml \
    examples/gke-a3-highgpu/gke-a3-highgpu.yaml

  8. 메시지가 표시되면 (A)pply를 선택하여 청사진을 배포합니다. 청사진은 VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.

동적 워크로드 스케줄러 샘플 작업 실행

동적 워크로드 스케줄러 (flex-start 또는 큐 기반 프로비저닝)를 사용하여 클러스터를 프로비저닝한 경우 샘플 Kubernetes 작업을 제출하여 워크로드 예약을 검증할 수 있습니다.

동적 워크로드 스케줄러 프로비저닝 모드에 대한 자세한 내용은 큐 기반 프로비저닝을 사용하는 동적 워크로드 스케줄러 flex-start를 참조하세요.

샘플 작업 제출

해당 소비 옵션에 해당하는 탭을 선택하세요.

유연한 시작

이 태스크는 선택사항이며 flex-start로 클러스터를 프로비저닝한 경우에만 적용됩니다. flex-start에 구성된 워크로드에는 포드 사양에 cloud.google.com/gke-flex-start: "true" 노드 선택기가 필요합니다.

  1. 샘플 flex-start 작업을 제출합니다.

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex.yaml

  2. 작업 및 포드 상태를 모니터링합니다.

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    다음을 바꿉니다.

    • JOB_NAME: 작업의 이름입니다.
    • POD_NAME: 포드의 이름입니다.

  3. 작업이 완료되면 작업 리소스를 삭제합니다.

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex.yaml

큐 기반 프로비저닝

이 태스크는 선택사항이며 큐 기반 프로비저닝으로 클러스터를 프로비저닝한 경우에만 적용됩니다. 큐 기반 프로비저닝을 위해 구성된 워크로드에는 포드 사양에 다음 라벨과 주석이 필요합니다.

  • 라벨: kueue.x-k8s.io/queue-name: dws-local-queue
  • 주석: provreq.kueue.x-k8s.io/maxRunDurationSeconds: "MAX_RUN_DURATION"

자세한 내용은 큐 기반 프로비저닝의 워크로드 매니페스트 요구사항을 참조하세요.

  1. 샘플 큐 기반 프로비저닝 작업을 제출합니다.

    kubectl apply -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

  2. 작업 및 포드 상태를 모니터링합니다.

    kubectl get jobs
kubectl describe job JOB_NAME
kubectl get pods
kubectl describe pod POD_NAME

    다음을 바꿉니다.

    • JOB_NAME: 작업의 이름입니다.
    • POD_NAME: 포드의 이름입니다.

  3. 작업이 완료되면 작업 리소스를 삭제합니다.

    kubectl delete -f examples/dws-sample-workloads/sample-job-flex-queue.yaml

네트워크 성능 테스트

프로비저닝된 클러스터의 기능을 검증하는 것이 좋습니다. 이렇게 하려면 Google 환경에 최적화된 NVIDIA Collective Communications Library (NCCL) 테스트인 NCCL 테스트를 사용합니다.

재현 가능한 벤치마크 실행

Cluster Toolkit을 사용하여 클러스터를 만든 후 GitHub에서 제공하는 레시피에 따라 선택한 머신 시리즈에서 대규모 머신러닝 개방형 모델의 선행 학습 벤치마크를 재현할 수 있습니다.

각 레시피는 다음 작업을 완료하는 방법을 안내합니다.

  • 환경을 준비합니다.
  • 벤치마크를 실행합니다.
  • 벤치마크 결과를 분석합니다. 이 검토에는 추가 분석을 위한 벤치마크 결과와 세부 로그가 포함됩니다.

학습 및 기타 유형의 워크로드에 사용할 수 있는 모든 레시피를 보려면 GPU 레시피 GitHub 저장소를 참조하세요.

Cluster Toolkit에서 만든 리소스 삭제

이 페이지에서 사용한 리소스에 대한 반복 요금이 청구되지 않도록 하려면 gcluster destroy 명령어를 사용하여 VPC 네트워크 및 GKE 클러스터를 포함하여 Cluster Toolkit에서 프로비저닝한 리소스를 삭제합니다.

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

CLUSTER_NAME을 클러스터 이름으로 바꿉니다. Cluster Toolkit으로 만든 클러스터의 경우 클러스터 이름은 DEPLOYMENT_NAME 이름을 기반으로 합니다.

다음 단계