로컬 SSD 지원 원시 블록 스토리지 프로비저닝 및 사용

이 페이지에서는 로컬 SSD 스토리지를 Google Kubernetes Engine(GKE) 클러스터에 프로비저닝하는 방법과 클러스터의 노드에 연결된 로컬 SSD 지원 원시 블록 스토리지의 데이터를 사용하도록 워크로드를 구성하는 방법을 설명합니다.

이 로컬 SSD 옵션을 사용하면 기본 스토리지를 더 세밀하게 제어하고 포드에 대한 고유한 노드 수준 캐시를 빌드하여 애플리케이션 성능을 향상시킬 수 있습니다. 또한 필요에 따라 DaemonSet을 실행하여 RAID를 구성하고 디스크를 포맷해 파일 시스템을 로컬 SSD 디스크에 설치하여 이 옵션을 맞춤설정할 수 있습니다.

GKE에서 원시 블록 액세스를 위한 로컬 SSD 지원에 대한 자세한 내용은 로컬 SSD 정보를 참조하세요.

시작하기 전에

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

• Google Kubernetes Engine API를 사용 설정합니다.
Google Kubernetes Engine API 사용 설정
• 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.

로컬 SSD 지원 원시 블록 스토리지로 클러스터 또는 노드 풀 만들기

--local-nvme-ssd-block 옵션과 함께 gcloud CLI를 사용하여 로컬 SSD 지원 원시 블록 스토리지로 클러스터를 만듭니다.

클러스터나 노드 풀을 만들기 위해 실행하는 gcloud CLI 명령어는 사용 중인 머신 유형이 속한 머신 시리즈 세대에 따라 다릅니다. 예를 들어 N1 및 N2 머신 유형은 각각 1세대 및 2세대 머신 시리즈에 속하고 C3 머신 유형은 3세대 머신 시리즈에 속합니다.

로컬 SSD로 클러스터 만들기

gcloud container clusters create CLUSTER_NAME \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE \
    --release-channel CHANNEL_NAME

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --cluster-version CLUSTER_VERSION \
    --local-nvme-ssd-block

로컬 SSD로 노드 풀 만들기

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-version NODE_VERSION \
    --local-nvme-ssd-block

노드 풀의 노드는 cloud.google.com/gke-local-nvme-ssd=true 라벨과 함께 생성됩니다. 다음 명령어를 실행하여 라벨을 확인할 수 있습니다.

kubectl describe node NODE_NAME

노드 풀에 연결된 로컬 SSD마다 호스트 OS는 서수 폴더의 디스크에 액세스하는 심볼릭 링크와 범용 고유 식별자(UUID)를 사용하는 심볼릭 링크를 만듭니다. 예를 들어 --local-nvme-ssd-block 옵션을 사용하여 로컬 SSD가 3개 있는 노드 풀을 만들면 호스트 OS가 디스크에 다음 심볼릭 링크를 만듭니다.

• /dev/disk/by-id/google-local-ssd-block0
• /dev/disk/by-id/google-local-ssd-block1
• /dev/disk/by-id/google-local-ssd-block2

또한 호스트 OS는 디스크에 대한 UUID를 사용하여 다음 심볼릭 링크를 만듭니다.

• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID1
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID2
• /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID3

이렇게 하면 고유 식별자를 사용하여 디스크에 액세스할 수 있습니다.

로컬 SSD 볼륨 액세스

다음 예시에서는 로컬 SSD 지원 원시 블록 스토리지에 액세스하는 방법을 보여줍니다.

로컬 PersistentVolumes

PersistentVolumes을 사용하여 로컬 SSD 볼륨을 포드로 마운트할 수 있습니다.

PersistentVolume을 수동으로 만들거나 로컬 볼륨 정적 프로비저닝 도구를 실행하여 로컬 SSD에서 PersistentVolume을 만들 수 있습니다.

로컬 PersistentVolume 제한사항

• 클러스터 자동 확장 및 동적 프로비저닝은 로컬 PersistentVolume에서 지원되지 않습니다.

• GKE 클러스터를 업그레이드하거나 노드를 복구하면 Compute Engine 인스턴스가 삭제되므로 로컬 SSD 디스크에 있는 모든 데이터도 삭제됩니다.

• 영구 데이터에 로컬 SSD를 사용하는 클러스터나 노드 풀에는 노드 자동 업그레이드 또는 노드 자동 복구를 사용 설정하지 마세요. 애플리케이션 데이터를 먼저 백업한 후에 데이터를 새 클러스터 또는 노드 풀로 복원해야 합니다.

• 노드가 삭제, 업그레이드, 복구되거나 축소되면 로컬 PersistentVolume 객체는 자동으로 삭제되지 않습니다. 삭제된 노드와 연결된 비활성 로컬 PersistentVolume 객체를 주기적으로 스캔하고 삭제하는 것이 좋습니다.

수동으로 PersistentVolume 만들기

클러스터의 각 노드에서 각 로컬 SSD의 PersistentVolume을 수동으로 만들 수 있습니다.

PersistentVolume 객체의 nodeAffinity 필드를 사용하여 특정 노드의 로컬 SSD를 참조합니다. 다음 예시에서는 Linux를 실행하는 노드의 로컬 SSD에 대한 PersistentVolume 사양을 보여줍니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "gke-test-cluster-default-pool-926ddf80-f166"

이 예시에서는 로컬 SSD 디스크가 RAID에 대해 수동으로 구성되고 포맷된 후 gke-test-cluster-default-pool-926ddf80-f166 노드의 /mnt/disks/ssd0에 마운트됩니다. nodeAffinity 필드는 RAID에 대해 수동으로 구성된 로컬 SSD를 사용하는 노드에 워크로드를 할당하는 데 사용됩니다. 클러스터에 노드가 하나뿐이거나 모든 노드에 RAID를 구성한 경우에는 nodeAffinity 필드가 필요하지 않습니다.

해당 PersistenVolumeClaim 사양은 다음과 같습니다.

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: ssd-local-claim
  spec:
    accessModes:
    - ReadWriteOnce
    storageClassName: local-storage
    resources:
      requests:
        storage: 37Gi

PersistentVolume을 삭제한 경우 디스크에서 데이터를 수동으로 지워야 합니다.

로컬 볼륨 정적 프로비저닝 도구 실행

로컬 볼륨 정적 프로비저닝 도구를 사용하여 로컬 SSD의 PersistentVolume을 자동으로 만들 수 있습니다. 프로비저닝 도구는 각 노드에서 로컬 SSD 디스크를 관리하고 PersistentVolume을 생성 및 삭제하고 PersistentVolume이 해제되었을 때 로컬 SSD 디스크에서 데이터를 삭제하는 DaemonSet입니다.

로컬 볼륨 정적 프로비저닝 도구를 실행하려면 다음을 수행하세요.

1. DaemonSet을 사용하여 RAID를 구성하고 디스크를 포맷합니다.

   1. gke-daemonset-raid-disks.yaml 사양을 다운로드합니다.

   2. RAID 디스크 DaemonSet을 배포합니다. DaemonSet은 모든 로컬 SSD 디스크에서 RAID 0 배열을 설정하고 기기를 ext4 파일 시스템으로 포맷합니다.

      kubectl create -f gke-daemonset-raid-disks.yaml
      

2. gke-nvme-ssd-block-raid.yaml 사양을 다운로드하고 사양의 네임스페이스 필드를 필요에 맞게 수정합니다.

   사양에는 다음 리소스가 포함됩니다.

   • 프로비저닝 도구의 ServiceAccount
   • 다음 권한을 위한 ClusterRole 및 ClusterRoleBindings:
     • PersistentVolume 객체 만들기 및 삭제
     • 노드 객체 가져오기
   • GKE를 위한 프로비저닝 도구 설정이 포함된 ConfigMap
   • 프로비저닝 도구를 실행하기 위한 DaemonSet

3. 프로비저닝 도구를 배포합니다.

   kubectl create -f gke-nvme-ssd-block-raid.yaml
   

   프로비저닝 도구가 성공적으로 실행되면 클러스터의 RAID 로컬 SSD 기기에 대한 PersistentVolume 객체를 만듭니다.

4. 다음 PersistentVolumeClaim 매니페스트를 provisioner-pvc-example.yaml로 저장합니다.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: PVC_NAME
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 50Gi
     storageClassName: nvme-ssd-block
   

   PVC_NAME을 PersistentVolumeClaim 이름으로 바꿉니다.

5. PersistentVolumeClaim을 만듭니다.

   kubectl create -f provisioner-pvc-example.yaml
   

6. 다음 포드 매니페스트를 provisioner-pod-example.yaml로 저장합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
   spec:
     containers:
     - name: "shell"
       image: "ubuntu:14.04"
       command: ["/bin/sh", "-c"]
       args: ["echo 'hello world' > /cache/test.txt && sleep 1 && cat /cache/test.txt && sleep 3600"]
       volumeMounts:
       - mountPath: /cache
         name: local-ssd-storage
     volumes:
     - name: local-ssd-storage
       persistentVolumeClaim:
         claimName: PVC_NAME
   

   POD_NAME을 포드 이름으로 바꿉니다.

7. 포드를 만듭니다.

   kubectl create -f provisioner-pod-example.yaml
   

지연된 볼륨 결합 사용 설정

예약 성능 향상을 위해 volumeBindingMode: WaitForFirstConsumer를 사용하여 StorageClass를 만드는 것이 좋습니다. 이렇게 하면 PersistentVolumeClaim 바인딩이 포드 예약까지 지연되어 포드를 실행할 수 있는 적절한 노드에서 로컬 SSD가 선택됩니다. 이와 같이 예약 동작이 향상됨에 따라 실행 가능한 포드에 대한 노드를 선택할 때 사용 가능한 로컬 SSD가 있는 노드와 함께 포드 CPU, 메모리 요청, 노드 어피니티, 포드 어피니티, 안티어피니티, 여러 PersistentVolumeClaim 요청이 고려됩니다.

이 예시에서는 지연된 볼륨 결합 모드를 사용합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-nvme"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

지연된 결합으로 StorageClass를 만들려면 YAML 매니페스트를 로컬 파일에 저장하고 다음 명령어를 사용하여 클러스터에 적용합니다.

kubectl apply -f filename

문제 해결

문제 해결 안내는 GKE에서 스토리지 문제 해결을 참조하세요.

다음 단계

• 노드 풀에 대해 자세히 알아보기