이 가이드에서는 GKE 볼륨 포퓰레이터를 사용하여 동적 프로비저닝 중에 Cloud Storage 버킷의 대량 데이터를 Google Kubernetes Engine (GKE) Hyperdisk ML 볼륨에 미리 로드하는 방법을 설명합니다. 자세한 내용은 GKE 볼륨 파퓰레이터 정보를 참고하세요.
이 가이드는 스토리지를 만들고 할당하며 데이터 보안 및 액세스를 관리하는 스토리지 전문가를 대상으로 합니다. Trusted Cloud by S3NS 콘텐츠에서 참조하는 일반적인 역할과 예시 태스크를 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.
Hyperdisk ML을 사용하는 GKE 볼륨 포퓰레이터의 노드 풀 관리
Hyperdisk ML 볼륨을 채우기 위해 GKE 볼륨 포퓰레이터로 생성된 데이터 전송 작업을 성공적으로 실행하려면 효율적인 노드 풀 크기 조정, 프로비저닝, 확장 작업이 중요합니다. 컴퓨팅 클래스를 사용하여 이러한 특정 데이터 전송 작업의 머신 유형 및 크기와 같은 노드 요구사항을 정의합니다. 컴퓨팅 클래스를 사용하면 데이터 전송 프로세스의 비용과 성능을 제어할 수 있습니다. 자세한 내용은 커스텀 컴퓨팅 클래스의 이점을 참고하세요.
데이터 전송 작업에 가장 적합한 클러스터를 선택하려면 컴퓨팅 클래스가 Hyperdisk ML의 다양한 클러스터 유형과 어떻게 작동하는지를 이해하세요.
목표
이 가이드에서는 다음 작업을 수행합니다.
- 클러스터 생성, 컴퓨팅 클래스 정의, 권한 설정을 비롯하여 GKE 볼륨 포퓰레이터를 사용한 데이터 전송을 지원하도록 GKE 클러스터 환경을 구성합니다.
GCPDataSource커스텀 리소스를 만들어 소스 Cloud Storage 버킷을 지정합니다.- Hyperdisk ML의
StorageClass정의 GCPDataSource를 참조하여 Hyperdisk ML 볼륨에 데이터 입력을 트리거하는PersistentVolumeClaim만들기- 데이터 전송 확인
- 포드에서 채워진 볼륨을 사용합니다.
- 리소스를 삭제합니다.
시작하기 전에
다음 작업을 수행했는지 확인합니다.
GKE 및 Cloud Storage API를 사용 설정합니다.
Trusted Cloud by S3NS 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.
Google Cloud CLI 명령줄 도구를 다운로드하여 설치하거나 Cloud Shell을 사용하여
gcloud CLI및kubectl명령어를 실행합니다. Cloud Shell은 Trusted Cloud by S3NS에서 호스팅되는 리소스를 관리하는 데 사용되는 셸 환경입니다. gcloud 및 kubectl 명령줄 도구가 사전 설치되어 있습니다.Cloud Storage 버킷을 만들거나 기존 버킷을 사용합니다. 이 가이드에서는 모델 학습 데이터가 채워진 Cloud Storage 버킷이 이미 있다고 가정합니다.
드라이버가 명시적으로 사용 중지되었을 수 있는 기존 Standard 클러스터에서 Compute Engine Persistent Disk CSI 드라이버를 사용 설정합니다. 새 Autopilot 및 Standard 클러스터에서 GKE는 기본적으로 드라이버를 사용 설정합니다. 생성하는 대상 Hyperdisk ML 스토리지는 Compute Engine Persistent Disk CSI 드라이버로 관리해야 합니다.
클러스터에 GKE용 워크로드 아이덴티티 제휴를 사용 설정합니다. 이렇게 하면 GKE 볼륨 포퓰레이터에서 사용하는 Kubernetes 서비스 계정이 소스 Cloud Storage 버킷에 액세스할 수 있습니다. 자세한 내용은 필요한 권한 설정을 참고하세요.
요구사항
GKE 볼륨 포퓰레이터를 사용하여 데이터를 전송하려면 다음 요구사항을 충족해야 합니다.
- GKE 클러스터에서 버전
1.33.2-gke.4780000이상을 실행해야 합니다. GCPDataSource커스텀 리소스는 GKE 워크로드와 동일한 네임스페이스에 있어야 합니다. 여러 네임스페이스에 걸쳐 있는 데이터 소스는 지원되지 않습니다.- 컴퓨팅 클래스를 만들 때 지원되는 VM을 선택합니다. 선택한 머신 유형에 충분한 할당량이 프로젝트에 있는지 확인합니다.
gcs-to-hdml-compute-class컴퓨팅 클래스 이름은 전송 작업에 대해 사전 정의되어 있으며 컴퓨팅 클래스를 만들 때 정확하게 지정해야 합니다.
비용
GKE 볼륨 포퓰레이터를 사용하는 데는 직접적인 비용이 들지 않지만 스토리지 및 데이터 전송에는 요금이 청구됩니다. 관련 간접비에는 다음이 포함됩니다.
- GKE에 사용되는 Compute Engine 인스턴스: 데이터 전송 작업을 실행하는 데 사용되는 노드의 비용입니다. 노드 관리 및 비용 영향은 클러스터 유형에 따라 다릅니다. 자세한 내용은 GKE 클러스터 만들기의 각 클러스터 유형을 참고하세요.
- 전송 작업 노드 크기: 최적의 전송 성능을 위해 전송 작업은 기본적으로 vCPU가 24개인 노드를 확장합니다. 이는 모든 클러스터 유형에 적용됩니다. 특정 비용 또는 성능 최적화를 위해 노드 크기와 유형을 조정하려면 컴퓨팅 클래스를 만들 때 조정하면 됩니다.
- Cloud Storage 버킷에 사용된 스토리지: 자세한 내용은 Cloud Storage 가격 책정을 참고하세요.
- Hyperdisk ML 볼륨 비용: 여기에는 생성한 Hyperdisk ML 볼륨의 스토리지 용량과 성능 (IOPS/처리량)이 포함됩니다. 자세한 내용은 Hyperdisk 가격 책정을 참고하세요.
개발 환경 준비
이 섹션에서는 적절한 하드웨어로 GKE 클러스터 인프라를 만들고 Cloud Storage의 데이터에 액세스하는 데 필요한 권한을 설정합니다.
Hyperdisk ML과 함께 GKE 볼륨 포퓰레이터를 사용하기 위해 클러스터를 만들기 전에 컴퓨팅 클래스가 다양한 유형의 클러스터에 적용되는 방식과 노드 관리를 담당하는 주체(GKE 또는 사용자)를 파악하세요.
Hyperdisk ML의 다양한 클러스터 유형에서 컴퓨팅 클래스가 작동하는 방식
GKE 볼륨 포퓰레이터는 커스텀 컴퓨팅 클래스를 사용하여 데이터 전송 작업에 사용할 노드 유형을 결정합니다. 다음 표에서는 클러스터 구성에 따른 컴퓨팅 클래스의 동작을 설명합니다.
| 고려사항 | GKE Autopilot 및 노드 자동 프로비저닝이 있는 GKE Standard | 노드 자동 프로비저닝이 없는 GKE Standard |
|---|---|---|
| 컴퓨팅 클래스 설정 | nodePoolAutoCreation 사용 설정됨 |
nodePoolAutoCreation 사용 중지됨 |
| 노드 관리 | GKE는 노드를 자동으로 만들고 관리합니다. | 노드를 수동으로 만들고 관리합니다. |
| 노드 확장 | 자동 | 수동 |
| 노드 라벨 지정 | 해당 없음 | 노드에 cloud.google.com/compute-class=gcs-to-hdml-compute-class 라벨을 지정해야 합니다. |
| 추가 정보 | 노드 자동 프로비저닝 및 컴퓨팅 클래스 | 수동으로 생성된 노드 풀 구성 |
GKE는 PersistentVolumeClaim의 PersistentVolume를 프로비저닝한 후 데이터 전송 작업을 시작합니다. Hyperdisk ML 볼륨을 채우려면 이 PersistentVolumeClaim가 Cloud Storage의 소스 데이터를 정의하는 GCPDataSource을 참조해야 합니다.
GKE 클러스터 만들기
GKE 버전 1.33.2-gke.4780000 이상을 사용하는 Standard 또는 Autopilot 클러스터를 사용하여 데이터 전송 파이프라인을 배포할 수 있습니다. 각 클러스터 유형에는 고유한 장점이 있으며 서로 다른 가격 책정 모델이 있습니다.
- 더 쉬운 클러스터 관리, 비용 효율성, 자동 확장을 위해 Autopilot을 선택하세요.
- 노드 프로비저닝을 더 세부적으로 제어하면서 자동 확장이 필요한 경우 노드 자동 프로비저닝이 사용 설정된 Standard를 선택합니다.
- 최대한의 제어가 필요하고 노드 프로비저닝, 확장, 유지관리의 모든 측면을 관리하는 데 문제가 없다면 노드 자동 프로비저닝이 사용 설정되지 않은 표준을 선택하세요.
Autopilot
GKE Autopilot 클러스터에서 GKE는 데이터 전송 작업에 필요한 노드의 생성 및 삭제를 자동으로 처리합니다. 전송 작업이 완료되면 노드 리소스가 자동으로 축소됩니다. 전송 포드 또는 포드가 실행된 노드를 수동으로 삭제할 필요는 없습니다.
새 Autopilot 클러스터를 만들려면 다음 명령어를 실행합니다.
gcloud container clusters create-auto CLUSTER_NAME \ --location=LOCATION \ --cluster-version=CLUSTER_VERSION
다음을 바꿉니다.
CLUSTER_NAME: 만들려는 클러스터의 이름입니다.LOCATION: 클러스터의 컴퓨팅 리전입니다. 예를 들면us-central1입니다.CLUSTER_VERSION: 클러스터의 GKE 버전입니다. 이 가이드에서는1.33.2-gke.4780000를 사용합니다.
Standard (노드 자동 프로비저닝 포함)
노드 자동 프로비저닝이 사용 설정된 GKE Standard 클러스터에서 GKE는 데이터 전송 작업에 필요한 노드의 생성 및 삭제를 자동으로 처리합니다. 전송 작업이 완료되면 노드 리소스가 자동으로 축소됩니다. 전송 포드 또는 포드가 실행된 노드를 수동으로 삭제할 필요는 없습니다.
노드 자동 프로비저닝이 사용 설정된 새 표준 클러스터를 만들려면 다음 명령어를 실행합니다.
gcloud container clusters create CLUSTER_NAME \ --cluster-version=CLUSTER_VERSION \ --location=LOCATION \ --project=PROJECT_ID \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-autoprovisioning \ --min-cpu MINIMUM_CPU \ --min-memory MINIMUM_MEMORY \ --max-cpu MAXIMUM_CPU \ --max-memory MAXIMUM_MEMORY \ --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only
다음을 바꿉니다.
CLUSTER_NAME: 노드 자동 프로비저닝이 사용 설정된 클러스터의 이름입니다.CLUSTER_VERSION: 클러스터의 GKE 버전입니다. 이 가이드에서는1.33.2-gke.4780000를 사용합니다.LOCATION: 클러스터의 컴퓨팅 영역 또는 리전입니다. 예를 들면us-central1-a또는us-central1입니다.PROJECT_ID: Trusted Cloud by S3NS 프로젝트 ID입니다.MINIMUM_CPU: 자동 프로비저닝할 최소 vCPU 수입니다. 예를 들면10입니다.MINIMUM_MEMORY: 자동 프로비저닝할 최소 메모리 양(GiB)입니다. 예를 들면200입니다.MAXIMUM_CPU: 자동 프로비저닝할 최대 vCPU 수입니다. 예를 들면100입니다. 이 한도는 수동으로 생성된 기존 노드 풀과 GKE에서 자동으로 생성할 수 있는 모든 노드 풀의 CPU 리소스 합계입니다.MAXIMUM_MEMORY: 자동 프로비저닝할 최대 메모리 양입니다. 예를 들면1000입니다. 이 한도는 기존의 수동으로 생성된 노드 풀과 GKE에서 자동으로 생성할 수 있는 모든 노드 풀의 메모리 리소스 합계입니다.
Standard (노드 자동 프로비저닝 없음)
노드 자동 프로비저닝이 사용 설정되지 않은 Standard 클러스터에서 GKE 볼륨 포퓰레이터를 사용하려면 기존 노드 풀을 사용하거나 전용 전송 노드 풀을 만들면 됩니다. 노드에는 전송 작업을 실행할 수 있는 용량과 compute-class와 일치하는 라벨이 있어야 합니다.
클러스터 및 노드 풀을 만들 때 gcs-to-hdml-compute-class 컴퓨팅 클래스를 노드 라벨로 지정합니다. 컴퓨팅 클래스 이름 gcs-to-hdml-compute-class은 전송 작업에 대해 사전 정의되어 있으며 정확하게 지정해야 합니다.
노드 자동 프로비저닝이 없는 새 Standard 클러스터와 해당 클러스터 내의 새 노드 풀을 만들려면 다음 명령어를 실행하세요.
gcloud container clusters create CLUSTER_NAME \ --cluster-version=CLUSTER_VERSION \ --location=LOCATION \ --num-nodes=1 \ --project=PROJECT_ID \ --workload-pool=PROJECT_ID.svc.id.goog gcloud container node-pools create NODE_POOL_NAME\ --cluster=CLUSTER_NAME \ --location=LOCATION \ --num-nodes=1 \ --machine-type=c3-standard-44 \ --node-labels="cloud.google.com/compute-class=gcs-to-hdml-compute-class" \ --node-taints="cloud.google.com/compute-class=gcs-to-hdml-compute-class:NoSchedule"
다음을 바꿉니다.
CLUSTER_NAME: 노드 자동 프로비저닝이 사용 설정되지 않은 상태로 만들려는 클러스터의 이름입니다.CLUSTER_VERSION: 클러스터의 GKE 버전입니다. 이 가이드에서는1.33.2-gke.4780000를 사용합니다.LOCATION: 클러스터의 컴퓨팅 리전입니다. 예를 들면us-central1-a또는us-central1입니다.PROJECT_ID: Trusted Cloud by S3NS 프로젝트 ID입니다.NODE_POOL_NAME: 새 클러스터에서 만들려는 노드 풀의 이름입니다. 이 노드 풀은 GKE 볼륨 포퓰레이터가 임시 데이터 전송 작업을 배포하는 데 사용됩니다.
불필요한 비용이 발생하지 않도록 데이터 전송이 완료된 후 gcloud container node-pools delete 명령어를 실행하여 수동으로 생성된 전송 노드 풀을 삭제하세요.
컴퓨팅 클래스 만들기
클러스터에서 노드로 사용할 수 있는 VM 유형을 지정하고 우선순위를 지정하는 컴퓨팅 클래스를 만들려면 다음 단계를 따르세요.
- 다음 매니페스트를
computeclass.yaml로 저장합니다.노드 자동 프로비저닝 사용
Autopilot 클러스터와 노드 자동 프로비저닝이 사용 설정된 Standard 클러스터의 경우
nodePoolAutoCreation섹션을 사용하여 컴퓨팅 클래스를 다음과 같이 정의합니다. 노드 자동 프로비저닝을 사용 설정하면 GKE가gcs-to-hdml-compute-class컴퓨팅 클래스 라벨이 있는 새 노드 풀을 자동으로 만듭니다.apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: gcs-to-hdml-compute-class spec: priorities: - machineFamily: c3 - machineFamily: c3d nodePoolAutoCreation: enabled: true whenUnsatisfiable: DoNotScaleUp
노드 자동 프로비저닝이 없는 경우
노드 자동 프로비저닝이 사용 설정되지 않은 Standard 클러스터의 경우
nodePoolAutoCreation섹션 없이 컴퓨팅 클래스를 다음과 같이 정의합니다.gcs-to-hdml-compute-class컴퓨팅 클래스 라벨을 사용하여 노드 풀을 이미 만들었는지 확인합니다.apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: gcs-to-hdml-compute-class spec: priorities: - machineFamily: c3 - machineFamily: c3d whenUnsatisfiable: DoNotScaleUp
데이터 전송 요구사항을 충족하는 호환
machineFamily를 지정할 수 있습니다. 적합한 머신 유형 선택에 관한 자세한 내용은 Hyperdisk ML의 머신 시리즈 지원을 참고하세요. - 컴퓨팅 클래스를 만들려면 매니페스트를 적용합니다.
kubectl apply -f computeclass.yaml
필요한 권한 설정
Cloud Storage 버킷에서 데이터를 전송하려면 GKE용 워크로드 아이덴티티 제휴에 필요한 권한을 설정하세요. 적절한 권한이 있으면 GKE 볼륨 포퓰레이터에서 생성한 전송 작업이 Cloud Storage 버킷에 액세스할 수 있습니다. 이 가이드에서는 전송할 모델 학습 데이터가 채워진 Cloud Storage 버킷이 이미 있다고 가정합니다.
Kubernetes 네임스페이스를 만듭니다.
kubectl create namespace NAMESPACENAMESPACE를 워크로드가 실행될 네임스페이스로 바꿉니다.기존 네임스페이스를 사용하는 경우 이 단계를 건너뛰세요.
Kubernetes 서비스 계정을 만듭니다.
kubectl create serviceaccount KSA_NAME \ --namespace=NAMESPACE다음을 바꿉니다.
KSA_NAME:GCPDataSource리소스에 지정할 Kubernetes 서비스 계정의 이름입니다. GKE 볼륨 포퓰레이터에서 생성된 전송 작업은 이 서비스 계정을 사용하여 Trusted Cloud by S3NS API를 인증합니다.NAMESPACE: 이전 단계에서 만든 Kubernetes 네임스페이스입니다.
IAM 서비스 계정에 Cloud Storage 버킷에 액세스할 수 있는 적절한 역할을 부여합니다.
gcloud storage buckets \ add-iam-policy-binding gs://GCS_BUCKET \ --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role "ROLE"다음을 바꿉니다.
GCS_BUCKET: Cloud Storage 버킷 이름PROJECT_NUMBER: 클러스터를 만든 Trusted Cloud by S3NS 프로젝트의 숫자 식별자입니다. 프로젝트 번호를 찾으려면 프로젝트 식별을 참고하세요.PROJECT_ID: Trusted Cloud by S3NS 프로젝트 ID입니다.NAMESPACE: 이전에 만든 네임스페이스로, 워크로드가 실행됩니다.KSA_NAME:GCPDataSource리소스에 지정한 Kubernetes 서비스 계정의 이름입니다. GKE 볼륨 포퓰레이터에서 생성된 전송 작업은 이 서비스 계정을 사용하여 Trusted Cloud by S3NS API를 인증합니다.ROLE: 서비스 계정에 부여할 IAM 역할입니다. 이 가이드에서는 버킷에서 읽을 수 있도록roles/storage.objectViewer역할을 부여합니다.
PROJECT_NUMBER,PROJECT_ID,NAMESPACE,KSA_NAME는 프로젝트의 GKE용 워크로드 아이덴티티 제휴 주 구성원 식별자를 구성하는 데 사용됩니다.
미리 로드된 데이터로 Hyperdisk ML 볼륨 만들기
다음 단계에 따라 Hyperdisk ML 볼륨을 만드는 데 필요한 GKE 인프라 및 구성을 설정하고 GKE 볼륨 포퓰레이터를 사용하여 자동 데이터 전송 프로세스를 트리거하고 관리합니다.
GCPDataSource맞춤 리소스 만들기를 사용하여 데이터 소스를 정의합니다.- 사용할 영구 스토리지 유형 (Hyperdisk ML 볼륨)을 정의하는 StorageClass를 만듭니다.
- PersistentVolumeClaim을 만들어 스토리지를 동적으로 프로비저닝하고 새로 프로비저닝된 Hyperdisk ML 볼륨에 액세스할 수 있도록 합니다.
- (선택사항) 데이터 전송 진행률을 확인합니다.
- Hyperdisk ML 볼륨을 사용하는 포드를 만들고 배포합니다.
GCPDataSource 커스텀 리소스 만들기
GKE에서 GCPDataSource 커스텀 리소스를 만들어 소스 Cloud Storage 버킷의 위치와 해당 버킷에 액세스하는 데 필요한 권한이 있는 서비스 계정을 지정합니다. 이 커스텀 리소스 정의 (CRD)는 GKE 볼륨 포퓰레이터에만 해당합니다.
다음 매니페스트를
gcpdatasource.yaml로 저장합니다.apiVersion: datalayer.gke.io/v1 kind: GCPDataSource metadata: name: GCP_DATA_SOURCE namespace: NAMESPACE spec: cloudStorage: serviceAccountName: KSA_NAME uri: gs://GCS_BUCKET/다음 값을 바꿉니다.
- GCP_DATA_SOURCE: Cloud Storage 버킷 참조를 보유한
GCPDataSourceCRD의 이름입니다. 자세한 내용은GCPDataSourceCRD 참조를 확인하세요. - NAMESPACE: 워크로드가 실행되는 동일한 네임스페이스
GCPDataSource커스텀 리소스는 이 네임스페이스에 생성됩니다. - KSA_NAME:
GCPDataSource리소스에 지정한 Kubernetes 서비스 계정의 이름입니다. GKE 볼륨 포퓰레이터에서 생성된 전송 작업은 이 서비스 계정을 사용하여 Trusted Cloud by S3NS API를 인증합니다.cloudStorage.serviceAccountName값은 필요한 권한 설정 섹션에서 GKE용 워크로드 아이덴티티 제휴에 설정한 Kubernetes 서비스 계정입니다. - GCS_BUCKET: Cloud Storage 버킷 이름
uri필드는 소스 데이터를 지정합니다.- 전체 버킷을 복사하려면
gs://GCS_BUCKET/를 사용합니다. - 버킷 내 특정 폴더에서 데이터를 복사하려면
gs://GCS_BUCKET/PATH_INSIDE_BUCKET/형식을 사용합니다. 예를 들어my-project-llm-models버킷 내의gemma/v1.0/weights/폴더에서 데이터를 복사하려면 URI는gs://my-project-llm-models/gemma/v1.0/weights/가 됩니다. 경로가 폴더를 나타내는 후행 슬래시로 끝나야 합니다.
- 전체 버킷을 복사하려면
- GCP_DATA_SOURCE: Cloud Storage 버킷 참조를 보유한
GCPDataSource리소스를 만들려면 매니페스트를 적용합니다.kubectl apply -f gcpdatasource.yaml
Hyperdisk ML StorageClass 만들기
pd.csi.storage.gke.io 프로비저닝 도구를 사용하여 선택한 영역에 Hyperdisk ML 볼륨을 프로비저닝하는 StorageClass를 만듭니다. 두 개 이상의 영역에서 데이터 사본에 액세스할 수 있도록 하려면 다중 영역 StorageClass를 만들면 됩니다. 다음은 다중 영역 StorageClass의 예입니다.
다음 매니페스트를
hdml-class.yaml로 저장합니다.apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hyperdisk-ml-single-zone parameters: type: hyperdisk-ml provisioned-throughput-on-create: "2400Mi" provisioner: pd.csi.storage.gke.io allowVolumeExpansion: false reclaimPolicy: Delete volumeBindingMode: Immediate allowedTopologies: - matchLabelExpressions: - key: topology.gke.io/zone values: - ZONEZONE을 Hyperdisk ML 볼륨을 만들려는 대상 영역으로 바꿉니다.- 노드 자동 프로비저닝이 없는 GKE Standard 클러스터의 경우
ZONE값은 노드를 만든 위치여야 합니다. - 노드 자동 프로비저닝이 있는 GKE Autopilot 또는 Standard 클러스터의 경우
ZONE값은 클러스터가 필요에 따라 확장하고 새 노드를 만들 수 있는 위치여야 합니다.
- 노드 자동 프로비저닝이 없는 GKE Standard 클러스터의 경우
(선택사항) 클러스터의 노드 위치를 나열하려면 다음 명령어를 실행합니다.
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(locations)"다음을 바꿉니다.
CLUSTER_NAME: 클러스터 이름입니다.LOCATION: 클러스터의 컴퓨팅 영역 또는 리전입니다. 예를 들면us-central1-a또는us-central1입니다.
StorageClass를 만들려면 매니페스트를 적용합니다.
kubectl apply -f hdml-class.yaml
PersistentVolumeClaim을 만들어 볼륨에 액세스
다음 매니페스트에서는 앞에서 만든 StorageClass를 참조하는 ReadOnlyMany 액세스 모드에서 PersistentVolumeClaim을 만드는 방법에 대한 예시를 보여줍니다.
다음 매니페스트를
volume-populator-pvc.yaml로 저장합니다.apiVersion: v1 kind: PersistentVolumeClaim metadata: name: PVC_NAME namespace: NAMESPACE spec: accessModes: - ReadOnlyMany storageClassName: hyperdisk-ml-single-zone resources: requests: storage: DISK_SIZE dataSourceRef: apiGroup: datalayer.gke.io kind: GCPDataSource name: GCP_DATA_SOURCE다음 값을 바꿉니다.
PVC_NAME: 데이터를 전송할 PersistentVolumeClaim의 이름입니다.NAMESPACE: 워크로드가 실행되는 네임스페이스입니다.DISK_SIZE: 데이터를 채우기 위해 생성될 디스크의 크기(GB)입니다. 데이터를 성공적으로 채우려면 요청된 디스크 크기가 Cloud Storage 버킷에 있는 모델 데이터의 크기보다 커야 합니다. Hyperdisk ML 볼륨의 지원 범위를 준수하려면DISK_SIZE값이 4Gi보다 커야 합니다. 자세한 내용은 Hyperdisk 볼륨 크기 한도를 참고하세요.GCP_DATA_SOURCE: Cloud Storage 버킷 참조를 보유한GCPDataSourceCRD의 이름입니다.
PVC에 선택적 주석을 추가하여 데이터 전송을 맞춤설정할 수 있습니다. 이러한 주석은 Hyperdisk ML 볼륨에 데이터를 복사하는 기본 전송 작업의 동작에 영향을 미칩니다.
volume-populator.datalayer.gke.io/cpu-request: 이 주석을 사용하여 전송Job의 다른 CPU 리소스 요청을 지정합니다. 다른 CPU 리소스 요청을 지정하지 않으면 PVC는 전송 성능을 최적화하기 위해 기본적으로 vCPU 24개를 요청합니다.volume-populator.datalayer.gke.io/transfer-path: 이 주석을 사용하여GCPDataSource리소스에서 복사된 데이터를 저장할 새 볼륨 내의 대상 경로를 지정합니다. 다른 경로를 지정하지 않으면 데이터가 Hyperdisk ML 볼륨 내의 루트 경로에 복사됩니다.
PVC를 만들려면 매니페스트를 적용합니다.
kubectl apply -f volume-populator-pvc.yaml
다음 사항을 참고하세요.
- StorageClass에서
volumeBindingMode필드를immediate로 설정하면 PVC를 배포하는 즉시 데이터 전송이 트리거됩니다. - StorageClass의
volumeBindingMode필드를WaitForFirstConsumer로 설정하면 PVC를 요청하는 포드를 배포하고 해당 포드가 노드에 성공적으로 예약된 후에만 데이터 전송이 트리거됩니다. Pod는 예약할 수 있지만 데이터 전송이 완료되고 볼륨을 사용할 준비가 될 때까지 컨테이너는 시작을 기다립니다.
데이터 전송 진행률을 확인하려면 데이터 전송 진행률 보기를 참고하세요. 리소스 프로비저닝 또는 데이터 전송 중에 오류가 발생하면 GKE 볼륨 포퓰레이터 데이터 전송 문제 해결을 참고하세요.
(선택사항) 데이터 전송 진행률 보기
이 섹션에서는 Cloud Storage 버킷에서 Hyperdisk ML 볼륨으로의 데이터 전송 진행 상황과 성공 여부를 추적하는 방법을 보여줍니다.
PersistentVolumeClaim의 상태를 확인하려면 다음 명령어를 실행합니다. PersistentVolumeClaim 바인딩 작업이 완료되는 데 너무 오래 걸리는 경우에도 이 명령어를 실행할 수 있습니다.
kubectl describe pvc PVC_NAME -n NAMESPACE다음을 바꿉니다.
PVC_NAME: 볼륨에 액세스하기 위한 PersistentVolumeClaim 만들기 섹션에서 만든 PVC의 이름입니다.NAMESPACE: 이 가이드 전체에서 사용되는 네임스페이스로, 필요한 권한 설정 섹션에서 만들었습니다.
출력에서 PersistentVolumeClaim 이벤트를 검토하여 데이터 전송 진행 상황을 모니터링합니다. GKE는 이벤트를 1분에 한 번 정도 로깅합니다. 출력은 다음과 비슷합니다.
Name: vp-pvc Namespace: default StorageClass: hyperdisk-ml-single-zone Status: Bound Volume: pvc-f7ae2ee2-106d-4b87-b458-481a3ff82b62 Labels: <none> Annotations: pv.kubernetes.io/bind-completed: yes pv.kubernetes.io/bound-by-controller: yes volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io Finalizers: [kubernetes.io/pvc-protection] Capacity: 200Gi Access Modes: ROX VolumeMode: Filesystem DataSource: APIGroup: datalayer.gke.io Kind: GCPDataSource Name: vp-gds Used By: verify-data-665cfd4dbf-mwc7t verify-data-665cfd4dbf-n7xw9 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 9m8s persistentvolume-controller Error saving claim: Operation cannot be fulfilled on persistentvolumeclaims "vp-pvc": the object has been modified; please apply your changes to the latest version and try again Normal Provisioning 9m5s pd.csi.storage.gke.io_gke-f110123a1cbd44cdaa7a-921b-b1f4-vm_1a100bd9-5231-4f20-8e65-1f8e995a03c0 External provisioner is provisioning volume for claim "default/vp-pvc" Normal Provisioning 9m5s external-provisioner Assuming an external populator will provision the volume Normal PopulateOperationStartSuccess 8m58s gkevolumepopulator-populator populateFn: Populate operation started for zone us-central1-c Normal TransferInProgress 8m58s (x2 over 8m58s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, transfer job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f in zone us-central1-c waiting for pod to get created Normal TransferInProgress 6m10s (x14 over 8m57s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, transfer job in zone us-central1-c with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f is still active with pod status as - Phase: Pending Normal ExternalProvisioning 3m35s (x24 over 9m5s) persistentvolume-controller Waiting for a volume to be created either by the external provisioner 'pd.csi.storage.gke.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered. Normal TransferJobCompleted 3m24s (x2 over 3m26s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f for zone us-central1-c completed successfully Normal TransferJobCompleted 3m24s (x2 over 3m26s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, transfer job for all zones have completed successfully Normal PopulateOperationFinished 3m24s (x2 over 3m26s) gkevolumepopulator-populator Populate operation finished Normal PopulatorFinished 3m19s (x3 over 3m20s) gkevolumepopulator-populator Populator finished
데이터 크기에 따라 채우기 작업이 시작되기까지 몇 분 정도 걸릴 수 있습니다. 몇 분 후에도 데이터 전송 진행률이 표시되지 않으면 GKE 볼륨 포퓰레이터 데이터 전송 문제 해결을 참고하세요.
다중 영역 Hyperdisk ML 볼륨 데이터 전송의 경우 데이터가 StorageClass에 지정된 모든 영역으로 성공적으로 전송된 경우에만 작업이 완료된 것으로 표시됩니다. 하나 이상의 영역에서 전송 작업이 실패하면 PVC가 있는 한 GKE 볼륨 포퓰레이터는 데이터 전송을 무기한으로 재시도합니다.
볼륨을 사용하는 포드 만들기 및 배포
데이터로 채워진 PVC의 콘텐츠를 확인하는 포드를 만들려면 다음을 실행하세요.
다음 매니페스트를
verify-data.yaml로 저장합니다.apiVersion: v1 kind: Pod metadata: name: verify-data namespace: NAMESPACE spec: nodeSelector: cloud.google.com/compute-class: gcs-to-hdml-compute-class containers: - name: verify-data image: busybox command: - sleep - infinity volumeMounts: - mountPath: /models name: mypvc volumes: - name: mypvc persistentVolumeClaim: claimName: PVC_NAME다음을 바꿉니다.
NAMESPACE: PVC가 있고verify-data포드를 만들려는 네임스페이스입니다.PVC_NAME: 볼륨에 액세스하기 위한 PersistentVolumeClaim 만들기 섹션에서 데이터 채우기를 위해 만든 PVC의 이름입니다.
다음 명령어를 사용하여 포드를 만듭니다.
kubectl create -f verify-data.yaml파일을 나열하려면 다음 명령어를 실행합니다.
kubectl exec -it verify-data -- /bin/sh # cd /models && ls
명령어가 성공하면 Cloud Storage 버킷 내의 /models 디렉터리에서 채워진 데이터를 확인할 수 있습니다.
삭제
불필요한 비용을 방지하고 잘못 구성되었거나 분리된 리소스를 삭제하려면 단계를 따라 PersistentVolumeClaim을 정상적으로 삭제하세요.
동적 프로비저닝 중에 PersistentVolumeClaim 삭제
동적 프로비저닝 중에 데이터가 전송되는 동안 PersistentVolumeClaim을 삭제해야 하는 경우 단계적 삭제를 위해 다음 단계를 따르세요. 정상적인 삭제를 완료하는 데 다소 시간이 걸릴 수 있습니다.
삭제 프로세스 중에 다음 관련 변수를 바꿉니다.
POD_NAME: 볼륨을 사용하는 포드 만들기 및 배포 섹션에서 만든 포드의 이름입니다.NAMESPACE: PVC가 있는 네임스페이스입니다.PVC_NAME: 볼륨에 액세스하기 위한 PersistentVolumeClaim 만들기 섹션에서 만든 PVC의 이름입니다.GCP_DATA_SOURCE:GCPDataSource커스텀 리소스 만들기 섹션에서 만든GCPDataSource커스텀 리소스의 이름입니다.
워크로드 포드를 삭제합니다.
kubectl delete pod POD_NAME -n NAMESPACE임시 PersistentVolumeClaim의 이름을 찾습니다.
# Store the relevant environment variables export PVC_NAME=PVC_NAME export NAMESPACE=NAMESPACE# Check the status export PVC_UID=$(kubectl get pvc ${PVC_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.uid}') export TEMP_PVC=prime-${PVC_UID} echo ${TEMP_PVC}네임스페이스에서 생성된 PVC를 삭제합니다.
kubectl delete pvc PVC_NAME -n NAMESPACEPVC가
Terminating상태로 멈춰 있을 수 있습니다.NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE vp-pvc Terminating hyperdisk-ml <unset> 7m23s이 경우 최종자를 삭제하여 PVC를 수동으로 정리합니다.
kubectl patch pvc PVC_NAME -n NAMESPACE -p '{"metadata":{"finalizers":null}}'PVC가 삭제된 후에만
GCPDataSource리소스를 삭제합니다.GCPDataSource리소스를 먼저 삭제하면 PVC 삭제가 중단됩니다.kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE임시 리소스가 삭제되었는지 확인합니다.
다음 단계
- GKE 볼륨 포퓰레이터 정보를 알아봅니다.
- 데이터 전송 문제에 대한 도움말은 GKE 볼륨 포퓰레이터 데이터 전송 문제 해결을 참고하세요.
- 고급 Hyperdisk ML 워크로드 예시는 Hyperdisk ML을 통한 AI/ML 데이터 로딩 가속화를 참고하세요.