로컬 솔리드 스테이트 드라이브(SSD)는 단일 Compute Engine VM에 마운트할 수 있는 고정 크기 SSD 드라이브입니다. GKE에서 로컬 SSD를 사용하면 클러스터의 모든 노드에 연결된 영구적이지 않은(임시적인) 고성능 스토리지를 얻을 수 있습니다. 또한 로컬 SSD는 표준 디스크보다 높은 처리량과 낮은 지연 시간을 제공합니다.
버전 1.25.3-gke.1800 이상에서는 로컬 임시 스토리지나 원시 블록 스토리지에 NVMe 인터페이스로 로컬 SSD를 사용하도록 GKE 노드 풀을 구성할 수 있습니다.
표준 클러스터에서 GKE를 사용하는 경우 노드 풀을 만들 때 로컬 SSD 볼륨을 노드에 연결할 수 있습니다. 이렇게 하면 emptyDir 볼륨 또는 로컬 PersistentVolume을 사용하는 워크로드의 임시 스토리지 성능이 향상됩니다. 클러스터의 머신 유형 제한 및 프로젝트 할당량 내에서 로컬 SSD로 노드 풀을 만들 수 있습니다.
로컬 SSD 디스크는 노드 하나에만 연결되고 노드 자체는 임시적입니다. 워크로드는 언제든지 다른 노드에 예약될 수 있습니다.
성능 및 머신 유형별로 허용되는 SSD 디스크 수와 같은 로컬 SSD의 이점과 제한사항에 대한 자세한 내용은 Compute Engine 문서의 로컬 SSD를 참조하세요.
GKE에 로컬 SSD를 선택하는 이유
워크로드에 다음 요구사항 중 하나라도 있으면 로컬 SSD가 적합합니다.
- AI 또는 머신 러닝, 분석, 일괄 처리, 로컬 캐싱, 인메모리 데이터베이스와 같이 데이터를 다운로드하고 처리하는 애플리케이션을 실행해야 합니다.
- 애플리케이션에 특별한 스토리지 요구가 있고 고성능 임시 스토리지에서 원시 블록 액세스가 필요합니다.
- 포드의 노드 수준 캐시와 같이 특별한 데이터 애플리케이션을 실행하고 로컬 SSD 볼륨을 작동해야 합니다. 이 방법을 사용하여 Aerospike 또는 Redis와 같은 인메모리 데이터베이스 애플리케이션에 대해 더 나은 성능을 유도할 수 있습니다.
임시 스토리지
--ephemeral-storage-local-ssd 옵션을 사용하여 노드 임시 스토리지에 로컬 SSD를 프로비저닝하는 것이 좋습니다. 이는 3세대 머신 시리즈를 사용하는 경우 기본값입니다.
이 방법은 emptyDir 볼륨, 컨테이너 쓰기 가능한 레이어, 로컬 SSD의 노드 임시 스토리지를 함께 구성하는 이미지를 배치합니다. 이점으로 기본 Persistent Disk보다 향상된 I/O 대역폭과 개선된 포드 시작 시간이 포함됩니다.
노드 임시 스토리지에 로컬 SSD를 사용하면 부팅 디스크 로컬 SSD 볼륨을 다른 용도로 사용할 수 없습니다. 권한이 있는 Daemonset, HostPath 또는 기타 메커니즘을 사용하여 /dev/nvme*와 같은 로컬 SSD 기기를 직접 수정하지 마세요. 그렇지 않으면 노드가 실패할 수 있습니다.
로컬 SSD 볼륨을 세밀하게 제어해야 하는 경우에는 대신 원시 블록 방식을 사용하세요.
블록 기기 스토리지
블록 기기 스토리지를 사용하면 크기가 고정된 블록의 데이터에 임의로 액세스할 수 있습니다. 일부 특수화된 애플리케이션은 파일 시스템 레이어로 인해 불필요한 오버헤드가 도입되는 등의 이유로 블록 기기 스토리지에 대한 직접 액세스가 필요합니다.
블록 기기 스토리지를 사용하는 일반적인 시나리오는 다음과 같습니다.
- 데이터가 기본 스토리지에 직접 구성되는 데이터베이스
- 자체적으로 특정 종류의 스토리지 서비스를 구현하는 소프트웨어(소프트웨어 정의 스토리지 시스템)
GKE 버전 v1.25.3-gke.1800 이상에서는 --local-nvme-ssd-block 옵션을 사용하여 원시 블록 로컬 NVMe SSD가 연결된 클러스터와 노드 풀을 만들 수 있습니다. 그런 다음 원하는 파일 시스템(예: ZFS 또는 HDFS)을 포맷하고 RAID를 구성하여 블록 스토리지를 맞춤설정할 수 있습니다. 이 옵션은 특히 로컬 SSD에서 지원하는 블록 스토리지에 액세스해야 하는 워크로드를 실행하기 위한 추가 제어가 필요한 경우에 적합합니다.
또한 포드 간에 데이터를 공유하도록 통합 데이터 캐시가 필요하고 데이터가 노드 수명 주기에 연결된 경우 로컬 SSD를 사용하는 블록 액세스 방법을 사용할 수 있습니다. 이렇게 하려면 RAID 구성으로 DaemonSet을 설치하고 파일 시스템을 포맷한 후 로컬 PersistentVolume을 사용하여 포드 간에 데이터를 공유합니다.
머신 요구사항
GKE 클러스터 및 노드 풀에 로컬 SSD를 프로비저닝하는 방법은 기본 머신 유형에 따라 다릅니다. GKE는 Compute Engine 1세대, 2세대, 3세대 머신 시리즈에서 로컬 SSD 볼륨을 지원합니다. 로컬 SSD 볼륨에는 n1-standard-1 이상의 머신 유형이 필요합니다.
기본 머신 유형인 e2-medium은 지원되지 않습니다.
머신 시리즈를 식별하려면 머신 유형 이름의 번호를 사용합니다. 예를 들어 N1 머신은 1세대이고 N2 머신은 2세대입니다.
사용 가능한 머신 시리즈와 유형의 목록은 Compute Engine 문서의 머신 계열 리소스 및 비교 가이드를 참조하세요.
1세대 및 2세대 머신 시리즈 요구사항
로컬 SSD에서 1세대 또는 2세대 머신 시리즈를 사용하려면 클러스터나 노드 풀에서 GKE 버전 1.25.3-gke.1800 이상이 실행되어야 합니다.
1세대 또는 2세대 머신 시리즈에서 로컬 SSD를 프로비저닝하려면 VM에서 사용할 로컬 SSD 볼륨 수를 지정합니다. 머신 시리즈와 허용 가능한 해당 로컬 SSD 수의 목록은 Compute Engine 문서의 유효한 로컬 SSD 수 선택을 참조하세요.
3세대 머신 시리즈 요구사항
로컬 SSD에서 3세대 머신 시리즈를 사용하려면 클러스터나 노드 풀에서 다음 GKE 버전 이상 중 하나가 실행되어야 합니다.
- 1.25.13-gke.200~1.26
- 1.26.8-gke.200~1.27
- 1.27.5-gke.200~1.28
- 1.28.1-gke.200~1.29
3세대 머신 시리즈의 경우 각 머신 유형은 로컬 SSD가 없거나 고정된 양의 로컬 SSD 볼륨으로 사전 구성됩니다. 포함할 로컬 SSD 볼륨 수를 지정하지 않습니다. 대신 클러스터에서 사용할 수 있는 로컬 SSD 용량은 암시적으로 VM 형태의 일부로 정의됩니다.
머신 시리즈와 허용 가능한 해당 로컬 SSD 수의 목록은 Compute Engine 문서의 유효한 로컬 SSD 수 선택을 참조하세요.
로컬 SSD 볼륨 사용 패턴
클러스터에서 로컬 SSD 볼륨을 사용하려면 다음 일반 단계를 수행합니다.
- 로컬 SSD가 연결된 노드 풀 프로비저닝: 연결된 로컬 SSD를 사용하여 GKE 노드 풀을 만들려면
create cluster명령어를 호출할 때 임시 스토리지나 원시 블록 스토리지 매개변수를 전달합니다. 로컬 SSD 매개변수를 설정하면 로컬 SSD가 연결된 GKE 노드 풀이 생성되고 선택한 매개변수에 따라 로컬 임시 스토리지나 원시 블록 스토리지로 구성됩니다. 로컬 SSD를 프로비저닝하는 옵션에 대한 자세한 내용은 로컬 SSD 매개변수를 참조하세요. - 로컬 SSD 볼륨에서 데이터 액세스: 로컬 SSD 볼륨의 데이터를 사용하려면 emptyDir 또는 로컬 영구 볼륨과 같은 Kubernetes 구성을 사용하면 됩니다. 이러한 옵션에 대한 자세한 내용은 로컬 SSD 액세스를 참조하세요.
GKE의 로컬 SSD 매개변수
다음 표에서는 GKE가 클러스터에서 로컬 SSD 스토리지를 프로비저닝할 수 있도록 제공하는 권장 매개변수를 요약 설명합니다. gcloud CLI를 사용하여 이러한 매개변수를 전달할 수 있습니다.
| 로컬 SSD 유형 | gcloud CLI 명령어 | GKE 가용성 | 로컬 SSD 프로필 |
|---|---|---|---|
| 임시 스토리지 로컬 SSD | gcloud container clusters create |
v1.25.3-gke.1800 이상 |
스토리지 기술: NVMe 포드 간 데이터 공유: 아니요 데이터 수명 주기: 포드 RAID 구성의 크기 및 필요: 최대 9TiB. GKE는 내부적으로 RAID를 자동으로 구성합니다. 형식: 파일 시스템(Kubernetes emptyDir) Kubernetes 스케줄러 통합: 기본적으로 완전히 통합됩니다. Kubernetes 스케줄러가 배치 전에 노드 공간을 보장하고 필요한 경우 노드를 확장합니다. 이 API 매개변수를 사용하는 방법을 알아보려면 로컬 SSD 지원 임시 스토리지 프로비저닝 및 사용을 참조하세요. |
| 로컬 NVMe SSD 블록 | gcloud container clusters create |
v1.25.3-gke.1800 이상 |
스토리지 기술: NVMe 포드 간 데이터 공유: 예(로컬 PV를 통해 공유) 데이터 수명 주기: 노드 RAID 구성의 크기 및 필요: 최대 9TiB. 더 큰 크기의 경우 RAID를 수동으로 구성해야 합니다. 형식: 원시 블록 Kubernetes 스케줄러 통합: 아니요(기본값). 노드 용량을 보장하고 사용량이 많은 인접 항목을 처리해야 합니다. 로컬 PV를 선택하면 예약이 통합됩니다. 이 API 매개변수를 사용하는 방법을 알아보려면 로컬 SSD 지원 원시 블록 스토리지 프로비저닝 및 사용을 참조하세요. |
기존 로컬 SSD 매개변수 지원
다음 표에서는 이러한 기존 로컬 SSD 매개변수와 권장 대체 옵션을 요약 설명합니다.
| 기존 로컬 SSD 매개변수 | gcloud CLI 명령어 | 로컬 SSD 프로필 | 로컬 SSD 매개변수의 권장 GA 버전 |
|---|---|---|---|
| 로컬 SSD 수 매개변수 | gcloud container clusters create |
스토리지 기술: SCSI 포드 간 데이터 공유: 예(로컬 PV를 통해 공유) 데이터 수명 주기: 노드 RAID 구성의 크기 및 필요: 375GiB. 더 큰 크기의 경우 RAID를 수동으로 구성해야 합니다. 형식: 파일 시스템(ext-4) Kubernetes 스케줄러 통합: 아니요(기본값). 노드 용량을 보장하고 사용량이 많은 인접 항목을 처리해야 합니다. 로컬 PV를 선택하면 예약이 통합됩니다. |
gcloud container clusters create |
| 임시 스토리지 매개변수(베타) | gcloud beta container clusters create |
스토리지 기술: NVMe 포드 간 데이터 공유: 아니요 데이터 수명 주기: 포드 RAID 구성의 크기 및 필요: 최대 9TiB. GKE는 내부적으로 RAID를 자동으로 구성합니다. 형식: 파일 시스템(Kubernetes emptyDir) Kubernetes 스케줄러 통합: 기본적으로 완전히 통합됩니다. Kubernetes 스케줄러가 배치 전에 노드 공간을 보장하고 필요한 경우 노드를 확장합니다. |
gcloud container clusters create |
| 로컬 SSD 볼륨 매개변수(알파) | gcloud alpha container clusters create |
스토리지 기술: NVMe 또는 SCSI 포드 간 데이터 공유: 아니요 데이터 수명 주기: 노드 RAID 구성의 크기 및 필요: 375GiB. 더 큰 크기의 경우 RAID를 수동으로 구성해야 합니다. 형식: 파일 시스템(ext-4) 또는 원시 블록 Kubernetes 스케줄러 통합: 아니요(기본값). 노드 용량을 보장하고 사용량이 많은 인접 항목을 처리해야 합니다. |
gcloud container clusters create |
로컬 SSD 액세스
다음 방법 중 하나로 로컬 SSD 볼륨에 액세스할 수 있습니다.
emptyDir 볼륨
GKE 버전 v1.25.3-gke.1800 이상에서는 --ephemeral-storage-local-ssd 옵션을 통해 임시 스토리지를 로컬 SSD에서 지원하는 emptyDir 볼륨으로 사용할 수 있습니다. 고성능 임시 스크래치 공간이 필요한 애플리케이션을 포함하여 대부분의 경우에 이 접근 방법이 권장됩니다.
GKE를 사용하면 NVMe 인터페이스를 사용하여 노드 임시 스토리지를 로컬 SSD에 마운트하도록 노드 풀을 구성할 수 있습니다.
자세한 내용은 이 예시를 참조하세요.
로컬 영구 볼륨
로컬 영구 볼륨은 단일 노드에 연결된 로컬 디스크를 나타냅니다. 로컬 영구 볼륨을 사용하면 포드 간에 로컬 SSD 리소스를 공유할 수 있습니다. 로컬 디스크가 로컬 SSD 디스크이므로 데이터는 계속 임시적입니다.
클러스터에서 다음 중 하나를 실행하는 경우에 이 접근 방법이 권장됩니다.
- StatefulSets 및 volumeClaimTemplates를 사용하는 워크로드
- 노드 풀을 공유하는 워크로드. 각 로컬 SSD 볼륨은 PersistentVolumeClaim을 통해 예약될 수 있으며 특정 HostPath는 포드 사양에서 직접 인코딩되지 않습니다.
- 동일한 로컬 SSD에 대해 데이터 중력이 필요한 포드. 포드는 항상 해당 로컬 PersistentVolume과 동일한 노드에 예약됩니다.
자세한 내용은 이 예시 및 오픈소스 Kubernetes 볼륨 문서를 참조하세요.
제한사항
애플리케이션에서 로컬 SSD 볼륨의 데이터에 대한 액세스 권한 손실을 적절하게 처리해야 합니다. 로컬 SSD 디스크에 기록된 데이터는 포드 또는 노드가 삭제, 복구, 업그레이드되거나 복구 불가 오류가 발생하는 경우 유지되지 않습니다.
임시 스토리지 로컬 SSD 매개변수는 포드 기반 데이터 수명 주기를 갖도록 로컬 SSD 볼륨을 구성하고 NVMe 로컬 SSD 블록 매개변수는 노드 기반 데이터 수명 주기를 갖도록 로컬 SSD 볼륨을 구성합니다.
영구 스토리지가 필요하면 내구성 스토리지 옵션(예: Persistent Disk, Filestore 또는 Cloud Storage)을 사용하는 것이 좋습니다. 또한 리전별 복제본을 사용하여 클러스터 수명 주기 또는 애플리케이션 수명 주기 운영 중에 데이터 손실 위험을 최소화할 수 있습니다.
노드 풀이 생성된 후에는 로컬 SSD 구성 설정을 수정할 수 없습니다. 기존 노드 풀의 로컬 SSD 구성을 사용 설정, 중지 또는 업데이트할 수 없습니다. 변경하려면 노드 풀을 삭제하고 새 노드 풀을 다시 만들어야 합니다.
emptyDir를 사용하는 포드는 로컬 SSD를 투명하게 사용합니다. 하지만 이는 해당 노드 풀에 있는 모든 노드의 모든 포드에 해당됩니다. GKE는 로컬 SSD에서 지원하는 로컬 SSD emptyDir 볼륨을 사용하는 일부 포드와 노드 부팅 디스크에서 지원하는 emptyDir 볼륨을 사용하는 다른 포드를 같은 노드 풀에 배치하는 것을 지원하지 않습니다. 노드 부팅 디스크로 지원되는 emptyDir 볼륨을 사용하는 워크로드의 경우 다른 노드 풀에서 워크로드를 예약해야 합니다.
로컬 SSD에는 Autopilot 클러스터 및 노드 자동 프로비저닝이 지원되지 않습니다.
스토리지 최적화(Z3) VM에서 실행되는 워크로드의 경우 로컬 SSD를 임시 스토리지로 사용하는 것이 좋습니다. Z3 노드는 유지보수 이벤트 중에 종료됩니다. 따라서 이러한 노드의 로컬 SSD에 있는 데이터를 유지보수 이벤트 중에 사용하지 못할 수 있으며 유지보수 후에는 데이터 복구가 보장되지 않습니다.