이 페이지에서는 로컬 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로 클러스터 만들기
1세대 또는 2세대
1세대 또는 2세대 머신 시리즈의 머신 유형을 사용하는 경우 --local-nvme-ssd-block count=NUMBER_OF_DISKS 옵션을 지정하여 클러스터를 만듭니다. 이 옵션은 각 노드에 연결할 로컬 SSD 디스크 수를 지정합니다.
최댓수는 머신 유형과 리전에 따라 달라집니다.
클러스터를 만들려면 다음 안내를 따르세요.
gcloud container clusters create CLUSTER_NAME \
--local-nvme-ssd-block count=NUMBER_OF_DISKS \
--machine-type=MACHINE_TYPE \
--release-channel CHANNEL_NAME
다음을 바꿉니다.
CLUSTER_NAME: 클러스터의 이름입니다.NUMBER_OF_DISKS: 각 노드에서 프로비저닝할 로컬 SSD 디스크 수입니다. 최대 디스크 수는 머신 유형 및 리전에 따라 달라집니다.MACHINE_TYPE: 사용할 1세대 또는 2세대 머신 유형입니다. 기본e2-medium유형으로는 로컬 SSD를 사용할 수 없으므로 이 필드를 지정해야 합니다.CHANNEL_NAME: GKE 버전이 1.25.3-gke.1800 이상인 출시 채널입니다.
3세대
3세대 머신 시리즈의 머신 유형을 사용하는 경우 개수 필드 없이 --local-nvme-ssd-block 옵션을 사용하여 클러스터를 만듭니다.
GKE는 VM 형태에 따라 클러스터의 로컬 SSD 용량을 자동으로 프로비저닝합니다. 최댓수는 머신 유형과 리전에 따라 달라집니다.
gcloud container clusters create CLUSTER_NAME \
--machine-type=MACHINE_TYPE \
--cluster-version CLUSTER_VERSION \
--local-nvme-ssd-block
다음을 바꿉니다.
CLUSTER_NAME: 클러스터의 이름입니다.MACHINE_TYPE: 3세대 머신 시리즈에서 사용할 머신 유형입니다.CLUSTER_VERSION: 3세대 머신 시리즈의 머신 유형에서 로컬 SSD를 지원하는 GKE 클러스터 버전입니다.
로컬 SSD로 노드 풀 만들기
1세대 또는 2세대
원시 블록 액세스에 로컬 SSD 디스크를 사용하는 노드 풀을 만들려면 다음 명령어를 실행합니다.
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--machine-type=MACHINE_TYPE \
--local-nvme-ssd-block count=NUMBER_OF_DISKS
다음을 바꿉니다.
POOL_NAME: 새 노드 풀의 이름입니다.CLUSTER_NAME: 클러스터의 이름입니다.MACHINE_TYPE: 사용할 1세대 또는 2세대 머신 유형입니다. 로컬 SSD를 기본e2-medium유형과 함께 사용할 수 없으므로 이 필드를 지정해야 합니다.NUMBER_OF_DISKS: 각 노드에서 프로비저닝할 로컬 SSD 디스크 수입니다. 최대 디스크 수는 머신 유형 및 리전에 따라 달라집니다.
3세대
3세대 머신 시리즈의 머신 유형을 사용하는 경우 개수 필드 없이 --local-nvme-ssd-block 옵션을 사용하여 클러스터를 만듭니다.
gcloud container node-pools create POOL_NAME \
--cluster=CLUSTER_NAME \
--machine-type=MACHINE_TYPE \
--node-version NODE_VERSION \
--local-nvme-ssd-block
다음을 바꿉니다.
POOL_NAME: 새 노드 풀의 이름입니다.CLUSTER_NAME: 클러스터의 이름입니다.MACHINE_TYPE: 3세대 머신 유형에서 사용할 머신 유형입니다.NODE_VERSION: 3세대 머신 시리즈의 머신 유형에서 로컬 SSD를 지원하는 GKE 노드 풀 버전입니다.
노드 풀의 노드는 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
PersistentVolume을 사용하여 로컬 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입니다.
로컬 볼륨 정적 프로비저닝 도구를 실행하려면 다음을 수행하세요.
DaemonSet을 사용하여 RAID를 구성하고 디스크를 포맷합니다.
gke-daemonset-raid-disks.yaml사양을 다운로드합니다.RAID 디스크 DaemonSet을 배포합니다. DaemonSet은 모든 로컬 SSD 디스크에서 RAID 0 배열을 설정하고 기기를
ext4파일 시스템으로 포맷합니다.kubectl create -f gke-daemonset-raid-disks.yaml
gke-nvme-ssd-block-raid.yaml사양을 다운로드하고 사양의 네임스페이스 필드를 필요에 맞게 수정합니다.사양에는 다음 리소스가 포함됩니다.
- 프로비저닝 도구의 ServiceAccount
- 다음 권한을 위한 ClusterRole 및 ClusterRoleBindings:
- PersistentVolume 객체 만들기 및 삭제
- 노드 객체 가져오기
- GKE를 위한 프로비저닝 도구 설정이 포함된 ConfigMap
- 프로비저닝 도구를 실행하기 위한 DaemonSet
프로비저닝 도구를 배포합니다.
kubectl create -f gke-nvme-ssd-block-raid.yaml프로비저닝 도구가 성공적으로 실행되면 클러스터의 RAID 로컬 SSD 기기에 대한 PersistentVolume 객체를 만듭니다.
다음 PersistentVolumeClaim 매니페스트를
provisioner-pvc-example.yaml로 저장합니다.kind: PersistentVolumeClaim apiVersion: v1 metadata: name: PVC_NAME spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi storageClassName: nvme-ssd-blockPVC_NAME을 PersistentVolumeClaim 이름으로 바꿉니다.PersistentVolumeClaim을 만듭니다.
kubectl create -f provisioner-pvc-example.yaml다음 포드 매니페스트를
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_NAMEPOD_NAME을 포드 이름으로 바꿉니다.포드를 만듭니다.
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에서 스토리지 문제 해결을 참조하세요.