Hyperdisk Storage Pool로 스토리지 성능 및 비용 최적화

Autopilot Standard

이 페이지에서는 Google Kubernetes Engine(GKE) 클러스터가 GKE Hyperdisk 스토리지 풀을 사용하여 디스크 전반에서 스토리지 용량, 처리량, IOPS를 풀링하고 공유하는 방법을 설명합니다.

개요

스토리지 풀은 물리적 스토리지 기기를 논리적으로 그룹화하므로 리소스를 세분화할 수 있습니다. 이러한 스토리지 풀 내에서 Google Cloud Hyperdisk를 프로비저닝하여 Hyperdisk 스토리지 풀을 만들 수 있습니다. Hyperdisk 스토리지 풀은 GKE 클러스터 디스크에서 공유할 수 있는 사전 프로비저닝된 용량, 처리량, IOPS를 제공합니다.

Hyperdisk 스토리지 풀을 사용하면 스토리지 리소스를 더 효율적이고 비용 효율적으로 관리할 수 있습니다. 이를 통해 중복 삭제 및 씬 프로비저닝과 같은 효율성 기술을 활용할 수 있습니다.

이 가이드에서는 us-east4-c 영역을 사용하여 Hyperdisk 균형 스토리지 풀 및 기타 리소스를 만듭니다.

계획 관련 고려사항

Hyperdisk 스토리지 풀을 프로비저닝하고 사용하기 전에 다음 요구사항 및 제한사항을 고려하세요.

스토리지 풀 만들기 및 관리

다음 요구사항 및 제한사항이 적용됩니다.

Compute Engine Hyperdisk 스토리지 풀의 모든 제한사항이 적용됩니다.
Hyperdisk 스토리지 풀에서 디스크 만들기의 모든 제한사항이 적용됩니다.
사용자가 만드는 Hyperdisk 스토리지 풀 유형에 따라 스토리지 풀에서 만들 수 있는 디스크 유형이 결정됩니다. Hyperdisk 스토리지 풀 유형을 참고하세요.

스토리지 풀에서 부팅 디스크 프로비저닝

다음 요구사항 및 제한사항이 적용됩니다.

클러스터의 노드 위치와 노드 풀의 노드 위치가 스토리지 풀의 영역과 정확히 일치하는지 확인합니다. 노드 자동 프로비저닝이 사용 설정된 경우에는 이 제한사항이 적용되지 않습니다. 노드 자동 프로비저닝은 필요한 경우 올바른 영역에 노드 풀을 자동으로 만들 수 있습니다.
포드를 실행하는 머신 유형이 Hyperdisk 균형 디스크 유형 연결을 지원하는지 확인합니다. Hyperdisk 처리량은 부팅 디스크로 지원되지 않습니다. Hyperdisk 머신 유형 지원 문서를 참고하세요.
수동으로 생성하거나 업데이트한 노드 풀에서만 스토리지 풀에 부팅 디스크를 프로비저닝할 수 있습니다.
노드 자동 프로비저닝을 사용하여 노드가 자동으로 생성되면 해당 노드의 부팅 디스크를 스토리지 풀 내에 배치할 수 없습니다.

스토리지 풀에서 연결된 디스크 프로비저닝

다음 요구사항 및 제한사항이 적용됩니다.

스토리지 풀에서 연결된 디스크를 프로비저닝하는 데 필요한 최소 GKE 버전은 1.29.2-gke.1035000 이상입니다.
Compute Engine 영구 디스크 CSI 드라이버가 사용 설정되어 있는지 확인합니다. Compute Engine 영구 디스크 드라이버는 기본적으로 새로운 Autopilot 및 Standard 클러스터에서 사용 설정되며 Autopilot 클러스터에서 사용 중지하거나 수정할 수 없습니다. 드라이버를 사용 설정하려면 기존 클러스터에서 Compute Engine Persistent Disk CSI 드라이버 사용 설정을 참고하세요.
스토리지 풀이 클러스터의 노드 위치와 노드 풀의 노드 위치 중 하나 이상에 있는지 확인합니다.
스토리지 풀에서는 Hyperdisk 처리량 및 Hyperdisk 균형 연결 디스크만 프로비저닝할 수 있습니다. 연결된 디스크의 유형은 스토리지 풀의 유형과 일치해야 합니다. 자세한 내용은 Hyperdisk 스토리지 풀 유형을 참고하세요.
포드를 실행하는 머신 유형이 스토리지 풀에서 사용 중인 디스크 유형의 연결을 지원하는지 확인합니다. 자세한 내용은 Hyperdisk 머신 유형 지원을 참고하세요.

할당량

Hyperdisk 스토리지 풀을 만들 때는 용량 및 성능에 대한 표준 또는 고급 프로비저닝을 사용하여 이를 구성하면 됩니다. 용량, 처리량 또는 IOPS의 할당량을 늘리려면 관련 할당량 필터에 더 높은 할당량을 요청하세요.

자세한 내용은 프로젝트 할당량 보기 및 할당량 상향 요청을 참고하세요.

Hyperdisk 균형 스토리지 풀에는 다음과 같은 할당량 필터를 사용하세요.

HDB-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: 고급 용량 프로비저닝으로 용량을 늘립니다.
HDB-STORAGE-POOL-TOTAL-ADVANCED-IOPS-per-project-region: 고급 성능 프로비저닝으로 IOPS를 늘립니다.
HDB-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: 고급 성능 프로비저닝으로 처리량을 늘립니다.
HDB-TOTAL-GB-per-project-region: 표준 용량 프로비저닝으로 용량을 늘립니다.
HDB-TOTAL-IOPS-per-project-region: 표준 성능 프로비저닝으로 IOPS를 늘립니다.
HDB-TOTAL-THROUGHPUT-per-project-region: 표준 성능 프로비저닝으로 처리량을 늘립니다.

Hyperdisk 처리량 스토리지 풀에는 다음과 같은 할당량 필터를 사용하세요.

HDT-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: 고급 용량 프로비저닝으로 용량을 늘립니다.
HDT-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: 고급 성능 프로비저닝으로 처리량을 늘립니다.
HDT-TOTAL-GB-per-project-region: 표준 용량 프로비저닝으로 용량을 늘립니다.
HDT-TOTAL-THROUGHPUT-per-project-region: 표준 성능 프로비저닝으로 처리량을 늘립니다.

예를 들어 고급 용량 프로비저닝을 사용하여 프로젝트 및 리전별로 Hyperdisk 균형 스토리지 풀의 총 용량을 늘리려면 다음 필터에 더 높은 할당량을 요청하세요.

hdb-storage-pool-total-advanced-capacity-per-project-region.

가격 책정

가격 세부정보는 Hyperdisk 스토리지 풀 가격 책정 을 참고하세요.

시작하기 전에

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

Google Kubernetes Engine API를 사용 설정합니다.

Google Kubernetes Engine API 사용 설정

이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.
참고: 기존 gcloud CLI 설치의 경우 compute/region 및 compute/zone 속성을 설정해야 합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다.

Hyperdisk 균형 스토리지 풀을 만들기 위한 지원되는 리전 및 영역을 검토합니다.

Hyperdisk 스토리지 풀 만들기

해당 스토리지 풀에서 부팅 디스크 또는 연결된 디스크를 프로비저닝하기 전에 Hyperdisk 스토리지 풀을 만듭니다. 자세한 내용은 Hyperdisk 스토리지 풀 만들기를 참고하세요.

지원되는 스토리지 영역 중 하나에 스토리지 풀을 만들어야 합니다.

예를 들어 다음 명령어를 사용하여 고급 용량 및 고급 성능이 적용된 Hyperdisk Balanced 스토리지 풀을 만들고 us-east4-c 영역에 10TB 용량, 10,000IOPS/s, 1,024MBps 처리량을 프로비저닝합니다.

export PROJECT_ID=PROJECT_ID
export ZONE=us-east4-c
gcloud compute storage-pools create pool-$ZONE \
    --provisioned-capacity=10tb --storage-pool-type=hyperdisk-balanced \
    --zone=$ZONE --project=$PROJECT_ID --capacity-provisioning-type=advanced \
    --performance-provisioning-type=advanced --provisioned-iops=10000 \
    --provisioned-throughput=1024

PROJECT_ID를 Google Cloud 계정 프로젝트 ID로 바꿉니다.

스토리지 풀 영역 검사

노드 자동 프로비저닝이 사용 설정된 Autopilot 클러스터 및 Standard 클러스터의 경우 클러스터 리전 내의 모든 영역에서 스토리지 풀을 만들 수 있습니다. 스토리지 풀을 만든 영역에 노드 풀이 없는 경우 GKE 클러스터 자동 확장 처리가 해당 영역에 새 노드 풀을 프로비저닝할 수 있을 때까지 포드는 Pending 상태로 유지됩니다.
노드 자동 프로비저닝이 없는 Standard 클러스터의 경우 스토리지 풀이 영역 리소스이므로 클러스터의 기본 노드 영역에 스토리지 풀을 만듭니다. --node-locations 플래그를 사용하여 클러스터의 노드 영역을 설정할 수 있습니다.
- 영역 클러스터의 경우 --node-locations를 지정하지 않으면 모든 노드가 클러스터의 기본 영역에 생성됩니다.
- 리전 클러스터의 경우 --node-locations를 지정하지 않으면 GKE는 리전 내에서 무작위로 선택된 3개의 영역에 작업자 노드를 배포합니다.

클러스터의 기본 노드 영역을 검사하려면 다음 명령어를 실행합니다.

gcloud container clusters describe CLUSTER_NAME  | yq '.locations'

CLUSTER_NAME을 부팅 디스크 또는 연결된 디스크를 프로비저닝하는 동안 만들 클러스터의 이름으로 바꿉니다.

Hyperdisk 스토리지 풀에서 GKE 부팅 디스크 프로비저닝

다음 중 하나를 수행할 때 Hyperdisk 스토리지 풀에 GKE 부팅 디스크를 프로비저닝할 수 있습니다.

새 GKE 클러스터를 만들 때
새 노드 풀을 만들 때
기존 노드 풀을 업데이트할 때

클러스터를 만들 때

스토리지 풀에 프로비저닝된 부팅 디스크가 있는 GKE 클러스터를 만들려면 다음 명령어를 사용합니다.

gcloud container clusters create CLUSTER_NAME \
    --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
    --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
    --zone=ZONE

다음을 바꿉니다.

CLUSTER_NAME: 만들려는 클러스터의 고유한 이름
DISK_TYPE: hyperdisk-balanced.로 설정. 비워 두면 디스크 유형이 기본적으로 Hyperdisk Balanced로 설정됩니다.
STORAGE_POOL,[...]: 클러스터의 부팅 디스크가 프로비저닝될 스토리지 풀 리소스 경로(예: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c)의 쉼표로 구분된 목록. 스토리지 풀 리소스 경로의 영역이 --node-locations의 영역과 일치하는지 확인합니다.
ZONE,[...]: 노드 풋프린트를 복제해야 하는 영역의 쉼표로 구분된 목록. 리전 클러스터의 경우 리전을 대신 지정할 수 있습니다. 모든 영역은 -location, --zone, 또는 --region 플래그로 지정된 클러스터와 동일한 리전에 있어야 합니다.
MACHINE_TYPE: 노드에 사용할 지원되는 머신 유형
ZONE: 클러스터를 만들려는 영역. —region 플래그를 사용하여 리전 클러스터를 만드세요.

노드 풀을 만들 때

스토리지 풀에 프로비저닝된 부팅 디스크가 있는 GKE 노드 풀을 만들려면 다음 명령어를 사용합니다.

gcloud container node-pools create NODE_POOL_NAME \
    --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
    --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
    --zone=ZONE --cluster=CLUSTER_NAME

다음을 바꿉니다.

NODE_POOL_NAME: 만들 노드 풀의 고유한 이름
DISK_TYPE: hyperdisk-balanced.로 설정. 비워 두면 디스크 유형이 기본적으로 Hyperdisk Balanced로 설정됩니다.
STORAGE_POOL,[...]: 클러스터의 부팅 디스크가 프로비저닝될 스토리지 풀 리소스 경로(예: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c)의 쉼표로 구분된 목록. 스토리지 풀 리소스 경로의 영역이 --node-locations의 값과 일치하는지 확인합니다.
ZONE,[...]: 노드 풋프린트를 복제해야 하는 영역의 쉼표로 구분된 목록. 모든 영역은 -location, --zone, 또는 --region 플래그로 지정된 클러스터와 동일한 리전에 있어야 합니다.
MACHINE_TYPE: 노드에 사용할 지원되는 머신 유형
ZONE: 노드 풀을 만들 영역입니다.
CLUSTER_NAME: 노드 풀을 만들려는 기존 클러스터

노드 풀을 업데이트할 때

update 명령어를 사용하여 노드 풀에서 스토리지 풀을 추가하거나 교체할 수 있습니다. 이 명령어는 노드 풀에서 스토리지 풀을 삭제하는 데 사용할 수 없습니다.

부팅 디스크가 스토리지 풀에 프로비저닝되도록 GKE 노드 풀을 업데이트하려면 다음 명령어를 사용합니다.

gcloud container node-pools update NODE_POOL_NAME \
  --storage-pools=STORAGE_POOL,[...] \
  --zone=ZONE --cluster=CLUSTER_NAME

NODE_POOL_NAME: 스토리지 풀을 사용하도록 업데이트하려는 기존 노드 풀의 이름
STORAGE_POOL,[...]: 기존 스토리지 풀 리소스 경로의 쉼표로 구분된 목록(예: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c). 스토리지 풀 리소스 경로의 영역이 업데이트 중인 노드 풀의 영역과 일치하는지 확인합니다.
ZONE: 노드 풀이 있는 영역
CLUSTER_NAME: 이 노드 풀이 속한 GKE 클러스터의 이름

GKE는 노드 풀의 업그레이드 전략에 따라 노드 풀을 업데이트합니다.

Hyperdisk 스토리지 풀에서 GKE 연결 디스크 프로비저닝

섹션 내용

저장소 풀에 프로비저닝된 연결된 디스크가 있는 새 GKE 클러스터를 만듭니다.
포드가 PersistentVolumeClaim(PVC)을 통해 요청할 때 PersistentVolume (PV)을 동적으로 프로비저닝하기 위한 StorageClass를 만듭니다. PV가 스토리지 풀의 공유 리소스를 사용하려면 StorageClass에서 storage-pools 매개변수를 사용하여 스토리지 풀을 지정합니다. 그런 다음 StorageClass는 PVC에서 포드에서 사용할 Hyperdisk 균형 볼륨을 프로비저닝하는 데 사용됩니다.
PVC를 만들어 GKE 클러스터에서 포드의 Hyperdisk 스토리지인 PV를 요청합니다. 이렇게 하면 스토리지 풀의 공유 리소스를 활용할 수 있습니다.
PVC를 사용하여 애플리케이션이 포드 재시작 및 재예약 후에도 영구 스토리지에 액세스할 수 있도록 배포를 만듭니다.

GKE 클러스터 만들기

시작하기 전에 연결된 디스크 프로비저닝 고려사항을 검토하세요.

Autopilot

gcloud CLI를 사용하여 Autopilot 클러스터를 만들려면 Autopilot 클러스터 만들기를 참고하세요.

예를 들면 다음과 같습니다.

gcloud container clusters create-auto CLUSTER_NAME --region=REGION

다음을 바꿉니다.

CLUSTER_NAME: 만들려는 클러스터의 고유한 이름
REGION: 클러스터를 만드는 리전

지원되는 머신 유형을 선택하려면 배포를 만들 때 cloud.google.com/compute-class: Performance nodeSelector를 지정합니다. 성능 컴퓨팅 클래스에서 사용할 수 있는 Compute Engine 머신 시리즈 목록은 지원되는 머신 시리즈를 참고하세요.

Standard

gcloud CLI를 사용하여 Standard 영역 클러스터를 만들려면 영역 클러스터 만들기를 참고하세요.

gcloud CLI를 사용하여 Standard 리전 클러스터를 만들려면 리전 클러스터 만들기를 참고하세요.

예를 들면 다음과 같습니다.

gcloud container clusters create CLUSTER_NAME --zone=ZONE --project=PROJECT_ID --machine-type=MACHINE_TYPE --disk-type="DISK_TYPE"

다음을 바꿉니다.

CLUSTER_NAME: 만들려는 클러스터의 고유한 이름
ZONE: 클러스터를 만드는 영역. —region 플래그를 사용하여 리전 클러스터를 만드세요.
PROJECT_ID: Google Cloud 계정 프로젝트 ID
MACHINE_TYPE: 노드에 사용할 지원되는 머신 유형
DISK_TYPE: hyperdisk-balanced.로 설정. 비워 두면 디스크 유형이 기본적으로 Hyperdisk Balanced로 설정됩니다.

StorageClass 만들기

Kubernetes에서 PV를 스토리지 풀 내에 만들려면 StorageClass를 사용합니다. 자세한 내용은 StorageClasses를 참고하세요.

원하는 처리량 또는 IOPS 수준으로 새 StorageClass를 만들려면 다음 단계를 따르세요.

프로비저닝 도구 필드에서 pd.csi.storage.gke.io를 사용합니다.
Hyperdisk 균형 스토리지 유형을 지정합니다.
storage-pools 매개변수를 사용하려는 특정 스토리지 풀의 목록으로 값을 지정합니다. 목록의 각 스토리지 풀은 projects/PROJECT_ID/zones/ZONE/storagePools/STORAGE_POOL_NAME. 형식으로 지정해야 합니다.
원하는 경우 성능 매개변수 provisioned-throughput-on-create 및 provisioned-iops-on-create.를 지정합니다.

각 Hyperdisk 유형에는 프로비저닝된 초기 디스크 크기로 결정된 성능을 위한 기본값이 포함됩니다. StorageClass를 만들 때는 Hyperdisk 유형에 따라 다음 매개변수를 선택적으로 지정할 수 있습니다. 이러한 매개변수를 생략하면 GKE는 디스크 유형 기본값에 따라 용량을 사용합니다.

매개변수	Hyperdisk 유형	사용
`provisioned-throughput-on-create`	Hyperdisk 균형, Hyperdisk 처리량	"Mi" 한정자를 사용하여 처리량 값(MiBps)을 표현합니다. 예를 들어 필요한 처리량이 250MiBps이면 StorageClass를 만들 때 `"250Mi"`를 지정합니다.
`provisioned-iops-on-create`	Hyperdisk 균형, Hyperdisk IOPS	IOPS 값은 한정자 없이 표현해야 합니다. 예를 들어 7,000 IOPS가 필요하면 StorageClass를 만들 때 `"7000"`를 지정합니다.

처리량 또는 IOPS에 허용되는 값에 대한 안내는 Hyperdisk 볼륨의 성능 수준 계획을 참조하세요.

다음 매니페스트를 사용하여 스토리지 풀 projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c에서 PV를 동적으로 프로비저닝하기 위한 storage-pools-sc라는 StorageClass를 만들고 적용합니다.

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storage-pools-sc
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced
  provisioned-throughput-on-create: "140Mi"
  provisioned-iops-on-create: "3000"
  storage-pools: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c
EOF

이 StorageClass에서 volumeBindingMode: WaitForFirstConsumer를 활용하면 PVC를 사용하는 포드가 생성될 때까지 PVC의 바인딩 및 프로비저닝이 지연됩니다. 이 접근 방식을 사용하면 PV가 조기에 프로비저닝되지 않고 PV와 이를 사용하는 포드 간에 영역이 일치합니다. 영역이 일치하지 않으면 포드는 Pending 상태로 유지됩니다.

PersistentVolumeClaim(PVC) 만들기

이전에 만든 storage-pools-sc StorageClass를 참조하는 PVC를 만듭니다.

다음 매니페스트를 사용하여 2048GiB를 Hyperdisk 밸런스드 볼륨의 대상 스토리지 용량으로 하는 my-pvc라는 이름의 PVC를 만듭니다.

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: storage-pools-sc
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2048Gi
EOF

PVC를 사용하는 배포 만들기

권장사항:

PersistentVolume과 함께 포드를 사용하는 경우 Deployment 또는 StatefulSet과 같은 워크로드 컨트롤러를 사용하세요.

Hyperdisk 균형을 지원하는 머신 시리즈가 있는 노드 풀에서 포드를 예약할 수 있도록 하려면 cloud.google.com/machine-family 노드 선택기로 배포를 구성합니다. 자세한 내용은 Hyperdisk의 머신 유형 지원을 참고하세요. 다음 샘플 배포에서는 c3 머신 시리즈를 사용합니다.

다음 매니페스트를 만들고 적용하여 이전 섹션에서 만든 PVC를 사용하여 Postgres 웹 서버를 배포하기 위한 포드를 구성합니다.

Autopilot

Autopilot 클러스터에서 cloud.google.com/compute-class: Performance nodeSelector를 지정하여 Hyperdisk 밸런스드 볼륨을 프로비저닝합니다. 자세한 내용은 포드에 전용 노드 요청을 참고하세요.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
        cloud.google.com/compute-class: Performance
      containers:
      - name: postgres
        image: postgres:14-alpine
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: my-pvc
EOF

Standard

노드 자동 프로비저닝이 사용 설정되지 않은 Standard 클러스터에서는 배포를 만들기 전에 지정된 머신 시리즈가 있는 노드 풀이 실행 중인지 확인합니다. 그렇지 않으면 포드가 예약되지 않습니다.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
      containers:
      - name: postgres
        image: postgres:14-alpine
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: my-pvc
EOF

배포가 성공적으로 생성되었는지 확인합니다.

  kubectl get deployment

Hyperdisk 인스턴스가 프로비저닝을 완료하고 READY 상태를 표시하는 데 몇 분 정도 걸릴 수 있습니다.

연결된 디스크가 프로비저닝되었는지 확인

my-pvc라는 이름의 PVC가 PV에 바인딩되었는지 확인합니다.

kubectl get pvc my-pvc

출력은 다음과 비슷합니다.


NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
my-pvc        Bound    pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6   2Ti        RWO            storage-pools-sc   2m24s

StorageClass 및 PVC에 지정된 대로 볼륨이 프로비저닝되었는지 확인합니다.

gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c

출력은 다음과 비슷합니다.

NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048

스토리지 풀에서 연결된 디스크 스냅샷 및 복원

디스크를 스토리지 풀 내부 또는 외부로 이동하는 것은 허용되지 않습니다. 디스크를 스토리지 풀 내부 또는 외부로 이동하려면 스냅샷에서 디스크를 다시 만드세요. 자세한 내용은 디스크 유형 변경을 참고하세요.

섹션 내용

포드에 프로비저닝된 디스크에 테스트 파일을 작성합니다.
볼륨 스냅샷을 만들고 해당 디스크에서 테스트 파일을 삭제합니다.
동일한 스토리지 풀 내의 새 디스크에 스냅샷을 복원하여 삭제된 데이터를 효과적으로 복구합니다.

테스트 파일 만들기

테스트 파일을 만들고 확인하려면 다음 단계를 따르세요.

Postgres 배포의 포드 이름을 가져옵니다.

kubectl get pods -l app=postgres

출력은 다음과 비슷합니다.

NAME                         READY   STATUS    RESTARTS   AGE
postgres-78fc84c9ff-77vx6   1/1     Running   0          44s

포드에서 테스트 파일 hello.txt를 만듭니다.

kubectl exec postgres-78fc84c9ff-77vx6 \
  -- sh -c 'echo "Hello World!" > /usr/share/data/hello.txt'

테스트 파일이 생성되었는지 확인합니다.

kubectl exec postgres-78fc84c9ff-77vx6 \
  -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!

볼륨 스냅샷 만들기 및 테스트 파일 삭제

스냅샷을 만들고 확인하려면 다음 단계를 따르세요.

볼륨의 스냅샷을 찍고 관리하는 방법을 지정하는 VolumeSnapshotClass를 만듭니다.

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapshotclass
driver: pd.csi.storage.gke.io
deletionPolicy: Delete
EOF

VolumeSnapshot을 만들고 my-pvc PersistentVolumeClaim에 바인딩된 볼륨에서 스냅샷을 찍습니다.

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  volumeSnapshotClassName: my-snapshotclass
  source:
    persistentVolumeClaimName: my-pvc
EOF

볼륨 스냅샷 콘텐츠가 생성되었는지 확인합니다.

kubectl get volumesnapshotcontents

출력은 다음과 비슷합니다.

NAME                                               READYTOUSE   RESTORESIZE     DELETIONPOLICY   DRIVER                  VOLUMESNAPSHOTCLASS   VOLUMESNAPSHOT   VOLUMESNAPSHOTNAMESPACE   AGE
snapcontent-e778fde2-5f1c-4a42-a43d-7f9d41d093da   false        2199023255552   Delete           pd.csi.storage.gke.io   my-snapshotclass      my-snapshot      default                   33s

스냅샷을 사용할 준비가 되었는지 확인합니다.

kubectl get volumesnapshot \
  -o custom-columns='NAME:.metadata.name,READY:.status.readyToUse'

출력은 다음과 비슷합니다.

NAME          READY
my-snapshot   true

포드 postgres-78fc84c9ff-77vx6에서 생성된 원본 테스트 파일 hello.txt를 삭제합니다.
```
kubectl exec postgres-78fc84c9ff-77vx6 \
    -- sh -c 'rm /usr/share/data/hello.txt'
```

볼륨 스냅샷 복원

볼륨 스냅샷 및 데이터를 복원하려면 다음 단계를 따르세요.

스냅샷에서 데이터를 복원하고 새 볼륨이 원래 볼륨과 동일한 스토리지 풀(storage-pools-sc) 내에 프로비저닝되도록 하는 새 PVC를 만듭니다. 다음 매니페스트를 적용합니다.

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-restore
spec:
  dataSource:
    name: my-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: storage-pools-sc
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2048Gi
EOF

방금 만든 새롭게 복원된 PVC를 사용하도록 postgres라는 기존 배포를 업데이트합니다. 다음 매니페스트를 적용합니다.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
      containers:
      - name: postgres
        image: google/cloud-sdk:slim
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: pvc-restore
EOF

postgres 배포의 일부인 새로 만든 포드의 이름을 가져옵니다.

kubectl get pods -l app=postgres

출력은 다음과 비슷합니다.

NAME                         READY   STATUS        RESTARTS   AGE
postgres-59f89cfd8c-42qtj   1/1     Running       0          40s

스냅샷에서 볼륨을 복원한 후 이전에 삭제된 hello.txt 파일이 새 포드(postgres-59f89cfd8c-42qtj)에 있는지 확인합니다.
```
kubectl exec postgres-59f89cfd8c-42qtj \
 -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!
```
이렇게 하면 스냅샷 및 복원 프로세스가 완료되었으며 스냅샷의 데이터가 포드에서 액세스할 수 있는 새 PV로 복원되었음을 확인할 수 있습니다.

스냅샷에서 만든 볼륨이 스토리지 풀 내에 있는지 확인합니다.

kubectl get pvc pvc-restore

출력은 다음과 비슷합니다.

NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
pvc-restore   Bound    pvc-b287c387-bc51-4100-a00e-b5241d411c82   2Ti        RWO            storage-pools-sc   2m24s

새 볼륨이 StorageClass 및 PVC에 지정된 대로 프로비저닝되었는지 확인합니다.

gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c

출력은 다음과 비슷합니다. 여기서 동일한 스토리지 풀에 프로비저닝된 새 볼륨 pvc-b287c387-bc51-4100-a00e-b5241d411c82를 볼 수 있습니다.


NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048
pvc-b287c387-bc51-4100-a00e-b5241d411c82  READY   3000              140                     2048

이렇게 하면 복원된 볼륨이 풀의 공유 리소스와 기능을 활용할 수 있습니다.

기존 볼륨을 스토리지 풀로 이전

스냅샷 및 복원을 사용하여 스토리지 풀 외부에 있는 볼륨을 스토리지 풀로 이전합니다.

다음 조건을 충족하는지 확인합니다.

새 PVC pvc-restore는 볼륨을 이동하려는 스토리지 풀을 가리키는 storage-pools 매개변수를 지정하는 StorageClass를 참조합니다.
스냅샷을 찍는 소스 PV는 storage-pools 매개변수를 지정하지 않는 StorageClass가 있는 PVC와 연결되어야 합니다.

스냅샷에서 새 볼륨으로 복원한 후에는 소스 PVC 및 PV를 삭제할 수 있습니다.

삭제

Google Cloud 계정에 비용이 청구되지 않도록 하려면 이 가이드에서 만든 스토리지 리소스를 삭제합니다. 먼저 스토리지 풀 내의 모든 디스크를 삭제한 다음 스토리지 풀을 삭제합니다.

부팅 디스크 삭제

노드 풀을 축소하여 노드를 삭제하거나 전체 노드 풀을 삭제하면 연결된 부팅 디스크가 자동으로 삭제됩니다. 클러스터를 삭제하여 클러스터 내의 모든 노드 풀의 부팅 디스크를 자동으로 삭제할 수도 있습니다.

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

연결된 디스크 삭제

Hyperdisk 스토리지 풀에 프로비저닝된 연결된 디스크를 삭제하려면 다음 단계를 따르세요.

PVC를 사용하는 포드를 삭제합니다.
```
kubectl delete deployments postgres
```
Hyperdisk 스토리지 풀 StorageClass를 사용하는 PVC를 삭제합니다.
```
kubectl delete pvc my-pvc
```
PVC pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6가 삭제되었는지 확인합니다.
```
gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
```

Hyperdisk 스토리지 풀 삭제

다음 명령어를 사용하여 Hyperdisk 스토리지 풀을 삭제합니다.

gcloud compute storage-pools delete pool-us-east4-c --zone=us-east4-c --project=my-project

다음 단계

GKE에서 스토리지 문제 해결 참고하기
GitHub에서 Persistent Disk CSI 드라이버 자세히 알아보기