Kubernetes 볼륨의 5가지 유형 및 작업 방법
이 페이지 공유하기
Yifat Perry
Kubernetes 볼륨이란?
Kubernetes 볼륨은 데이터를 포함하는 디렉터리로, Kubernetes 포드 내의 컨테이너가 액세스할 수 있습니다. 디렉터리의 위치, 이를 지원하는 저장 매체 및 그 내용은 사용 중인 볼륨의 특정 유형에 따라 달라집니다.
포드 내 컨테이너에서 실행 중인 프로세스는 다음과 같이 구성된 파일 시스템 뷰를 인식합니다.
- 컨테이너 이미지의 내용과 일치하는 루트 파일 시스템
- 컨테이너에 마운트된 볼륨(정의된 경우). 각 볼륨은 컨테이너 파일 시스템 내의 특정 경로에 마운트됩니다.
볼륨은 포드 템플릿의 .spec.containers[*].volumeMounts 필드에 정의됩니다. 각 포드 및 포드 내 각 컨테이너 이미지에 대해, 해당 컨테이너가 마운트할 볼륨과 마운트 경로를 지정해야 합니다(경로는 컨테이너마다 다를 수 있음).
Kubernetes에는 몇 가지 유형의 볼륨이 있습니다. 가장 중요한 것은 Kubernetes 노드에 로컬로 저장되며 포드가 재시작될 때 삭제되는 임시 볼륨과, 포드가 종료된 후에도 데이터를 유지하는 Kubernetes 영구 볼륨(PV)입니다.
이 문서의 내용:
- Kubernetes 볼륨 유형
- 영구 볼륨
- 임시 볼륨
- EmptyDir 볼륨
- Kubernetes hostPath 볼륨
- Kubernetes 볼륨 ConfigMap
- Kubernetes 볼륨 저장용 플러그인
- NFS
- CSI
- Kubernetes volumeMounts란?
- 포드 배포를 통한 Kubernetes 볼륨 생성
- NetApp Cloud Volumes ONTAP을 활용한 Kubernetes 볼륨 관리
5가지 유형의 Kubernetes 볼륨
Kubernetes는 다양한 볼륨을 지원하여 각 포드가 여러 볼륨 유형을 동시에 사용할 수 있도록 합니다. 임시 볼륨은 포드의 수명 주기에 종속되는 반면, 영구 볼륨은 포드의 수명 주기를 넘어 지속될 수 있습니다. 이는 Kubernetes가 포드가 더 이상 존재하지 않을 때 임시 볼륨을 삭제하는 반면, 영구 볼륨의 데이터는 유지한다는 의미입니다.
영구 볼륨
Kubernetes는 스토리지 프로비저닝과 소비를 추상화하는 API를 갖춘 PersistentVolume 하위 시스템을 제공합니다. 두 가지 API 리소스인 PersistentVolume(PV)과 PersistentVolumeClaim(PVC)과 함께 작동합니다.
PersistentVolume (PV)
PV는 클러스터 내에 위치한 스토리지 리소스입니다. 관리자는 PV를 수동으로 프로비저닝할 수 있으며, Kubernetes는 스토리지 클래스를 사용하여 PV를 동적으로 프로비저닝할 수 있습니다. 볼륨과 마찬가지로 PV도 플러그인이지만, 그 수명 주기는 PV를 사용하는 어떤 포드와도 독립적입니다.
PV는 iSCSI, NFS 및 클라우드 공급자 스토리지 시스템을 포함한 스토리지 구현의 세부 사항을 캡처하는 API 오브젝트로 작동합니다. 노드와 유사하게 작동하지만, 컴퓨팅 대신 스토리지 리소스를 제공합니다.
PersistentVolumeClaim(PVC)
PVC는 사용자가 생성한 스토리지 요청입니다. 포드와 유사하게 작동하지만, 노드 리소스 대신 PV 리소스를 소비합니다. PVC는 ReadWriteOnce, ReadWriteMany, ReadOnlyMany와 같은 크기 액세스 모드를 지정하여 특정 스토리지 리소스를 요청할 수 있습니다.
PVC는 사용자가 추상화된 스토리지 리소스를 소비할 수 있게 하지만, 사용자는 일반적으로 다양한 문제에 대해 서로 다른 속성을 가진 PV가 필요합니다. 이것이 바로 클러스터 관리자가 크기나 액세스 모드 이상의 차이점을 지닌 다양한 PV를 제공해야 하는 이유입니다. StorageClass 리소스를 통해 사용자에게 구현 세부 사항을 노출시키지 않고도 이를 수행할 수 있습니다.
관련 콘텐츠: Kubernetes PVC에 대한 가이드를 참조하십시오
임시 볼륨
임시 볼륨은 볼륨은 재시작 후에도 데이터를 영구적으로 저장하지 않습니다. 이들 볼륨은 포드의 수명 주기에 바인딩되어 있으므로, 포드와 함께 생성 및 삭제됩니다. 영구 볼륨의 가용성에 제한받지 않고 포드를 중지하고 재시작할 수 있게 합니다.
임시 볼륨은 배포 및 관리가 간단합니다. 포드 사양에서 인라인으로 지정할 수 있습니다. 임시 볼륨은 캐싱 서비스처럼 영구 스토리지가 필요하지 않은 애플리케이션에 이상적입니다.
EmptyDir 볼륨
Kubernetes가 노드에 포드를 할당할 때 emptyDir 볼륨이 생성됩니다. 이 볼륨의 수명은 해당 특정 노드에 존재하는 포드의 수명 주기와 연결되어 있습니다. emptyDir 볼륨은 컨테이너가 재시작되거나 중단될 때 재생성됩니다. 그러나 이 볼륨의 데이터는 노드에서 포드가 제거되거나, 충돌하거나, 종료될 때 삭제되고 손실됩니다.
emptyDir 볼륨을 생성한 후, 해당 볼륨 유형 이름을 포드 매니페스트 파일의 필드로 선언할 수 있습니다. 볼륨 속성 섹션 아래에 해당 값으로 빈 중괄호{}가 표시됩니다. EmptyDir 볼륨은주로 임시 데이터 스토리지에 적합합니다. 예를 들어, 디스크 기반 병합과 같은 임시 공간으로 사용할 수 있습니다.
emptyDir 볼륨을 해당 노드를 지원하는 매체에 저장할 수 있습니다. 예를 들어, 네트워크 스토리지나 SSD를 사용할 수 있습니다. 또는 emptyDir.medium 필드에 'memory'를 설정하면 Kubernetes가 RAM 기반 파일 시스템(tmpfs)을 마운트합니다. Kubernetes는 노드 재부팅 시 tmpfs를 지운다는 점에 유의하십시오.
Kubernetes hostPath 볼륨
hostPath 볼륨은 호스트 노드의 파일 시스템에서 디렉터리나 파일을 포드에 마운트합니다.
hostPath 볼륨의 주요 사용 사례는 다음과 같습니다.
- /var/lib/dockerhostPath를 사용하여 Docker 내부에 액세스가 필요한 컨테이너를 실행합니다.
- /sys hostPath를 사용하여 컨테이너 내에서 cAdvisor를 실행합니다.
- 포드가 hostPath를 지정할 수 있도록 허용하여 포드가 실행되기 전에 특정 hostPath가 존재해야 하는지, 그리고 생성되어야 하는지를 정의합니다.
- hostPath 볼륨의 유형 지정하여 필수 경로 속성 외에도 이 설정을 추가로 구성할 수 있습니다.
HostPath 볼륨 보안
HostPath 볼륨은 많은 보안 위험을 초래합니다. 가능하면 이러한 볼륨을 사용하지 마십시오. HostPath 볼륨을 반드시 사용해야 하는 경우, 필요한 디렉터리나 파일로만 범위를 제한하고 ReadOnly로 마운트해야 합니다.
주요 보안 위험은 다음과 같습니다.
- 노출된 자격 증명—HostPaths는 권한 있는 시스템 자격 증명 또는 권한 있는 API를 노출할 수 있습니다. 위협 행위자는 이를 이용해 클러스터의 다른 부분을 공격하거나 컨테이너 탈출에 활용할 수 있습니다.
- 루트 권한—기본 호스트에 생성된 모든 디렉터리나 파일은 루트만이 쓰기 권한을 가집니다. hostPath 볼륨에 쓰기를 수행하려면 호스트에서 파일 권한을 수정하거나, 권한이 부여된 컨테이너 내에서 루트 권한으로 프로세스를 실행해야 합니다.
AdmissionPolicy를 사용하여 HostPath 액세스를 을 특정 디렉터리로 제한할 수 있습니다. 하지만 이 정책은 volumeMounts가 readOnly 마운트를 사용하도록 요구하는 경우에만 유효합니다.
Kubernetes 볼륨 ConfigMap
ConfigMap은 포드에 구성 데이터를 주입할 수 있게 합니다. ConfigMap 내에 저장된 데이터는 configMap 볼륨 유형에서 참조될 수 있으며, 이후 포드 내에서 실행되는 컨테이너화된 애플리케이션에서 사용될 수 있습니다. ConfigMap을 참조할 때 볼륨 내에서 ConfigMap의 이름을 제공해야 합니다. Kubernetes를 사용하면 ConfigMap의 특정 항목에 대한 경로를 사용자 정의할 수 있습니다.
Kubernetes 볼륨 저장용 플러그인
Kubernetes는 Kubernetes 클러스터에 배포된 스토리지 장치에 대한 액세스를 제공하는 여러 스토리지 플러그인을 제공합니다. 이는 StorageClass 오브젝트를 사용하여 구현됩니다.
현재 Kubernetes에서 지원하는 주요 플러그인으로는 GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS 및 iSCSI가 있습니다. 이러한 플러그인에 대한 자세한 내용은 StorageClass 설명서를 참조하십시오.
두 가지 주목할 만한 스토리지 플러그인을 더 자세히 살펴보겠습니다.
NFS
NFS(Network File System)는 스토리지 장치를 로컬 드라이브로 마운트하기 위한 표준 프로토콜입니다. Kubernetes를 사용하면 NFS 볼륨을 컨테이너의 로컬 드라이브로 마운트할 수 있습니다. 레거시 코드는 종종 NFS를 통해 데이터에 액세스하기 때문에, 이 플러그인은 레거시 워크로드를 Kubernetes로 마이그레이션하는 데 매우 유용합니다.
NFS와 Kubernetes를 통해 데이터에 액세스하는 방법에는 두 가지가 있습니다.
- 임시 NFS 볼륨—기존 NFS 스토리지에 연결할 수 있습니다.
- NFS를 통한 PersistentVolumes—클러스터에 NFS를 통해 액세스하는 관리형 리소스를 설정할 수 있습니다.
CSI
CSI(Container Storage Interface)는 컨테이너 오케스트레이터가 관리하는 컨테이너에 스토리지 시스템을 노출할 수 있도록 하는 표준 인터페이스입니다. CSI는 스토리지 공급업체가 '트리 외부(out of tree)' 플러그인을 생성할 수 있도록 합니다. 이는 해당 플러그인이 Kubernetes 코드 저장소에 체크인될 필요가 없으며 Kubernetes와 함께 배포되지 않음을 의미합니다.
스토리지 공급업체에서 직접 제공하는 CSI 기반의 트리 외부 플러그인이 다수 존재합니다. CSI의 등장으로 스토리지 기술이 Kubernetes를 지원하는 것이 훨씬 쉬워졌습니다.
관련 컨텐츠: Container Storage Interface 가이드 읽기
Kubernetes volumeMounts란?
볼륨을 생성하고 포드가 이를 사용할 수 있도록 하는 데는 두 단계가 포함됩니다.
- 포드 템플릿의 spec:volumes 속성에 이를 선언한 후, 일부 노드에 포드를 배포합니다.
- spec:containers::volumeMounts 속성을 사용하여 볼륨을 특정 컨테이너에 마운트하기
이 단계들은 서로 밀접하게 연관되어 있습니다. 볼륨을 생성할 때는 반드시 컨테이너에 마운트해야 하며, 포드 템플릿에 선언하지 않은 볼륨은 마운트할 수 없습니다.
다음은 포드 템플릿 YAML 구성에서 볼륨 생성 및 마운팅을 모두 보여주는 예시입니다.
spec: containers: —name: my-app image: nginx volumeMounts: —name: my-volume mountPath: /app/config volumes: —name: my-volume
이 코드에서:
- volumes(하단)은 my-volume이라는 볼륨을 생성하고 이를 포드에 연결합니다.
- volumeMounts는 볼륨이 마운트되는 방식을 정의하며, 여기에는 컨테이너 내부에서 볼륨을 사용할 수 있게 해주는 파일 경로가 포함됩니다.
- 볼륨 선언과 volumeMounts 속성 모두에서 동일한 볼륨 이름을 사용하는 것이 필수적입니다.
포드 배포를 통한 Kubernetes 볼륨 생성
Kubernetes 볼륨을 생성하려면, 해당 볼륨을 선언하는 하나 이상의 포드를 배포합니다. 이를 수행하는 일반적인 방법은 Deployment 오브젝트를 통해 이루어집니다. 다음을 수행하는 Deployment 매니페스트의 예는 다음과 같습니다.
- 세 개의 포드를 배포하며, 각 포드에는 하나의 NGINX 컨테이너가 포함됩니다.
- emptyDir 볼륨을 선언합니다.
- 세 개의 컨테이너 각각의 볼륨을 루트에 마운트합니다.
apiVersion: apps/v1 kind: Deployment metadata: name: pods-with-volumes spec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: —name: my-container image: nginx:1.14.2 volumeMounts: —mountPath: / name: my-volume volumes: —name: my-volume emptyDir: {}
이 Deployment의 이름은 pods-with-volumes에 정의되어 있으며, 이는 Kubernetes 환경에서 참조하는 방식입니다.
이전 섹션에서 살펴본 것처럼, 이 Deployment 오브젝트는 볼륨을 생성하는 데 필요한 두 가지 작업을 수행합니다.
- spec:template:volumes 속성은 볼륨을 선언합니다.
- spec:containers::volumeMounts 속성은 볼륨을 컨테이너에 마운트합니다.
이 YAML 파일이 my-deployment.yaml이라는 이름으로 저장되어 있다고 가정해 보겠습니다. 다음 명령어를 사용하여 Kubernetes 클러스터에 Deployment를 생성할 수 있습니다:
kubectl apply -f my-deployment.yaml
Deployment가 예상된 볼륨으로 정상적으로 실행 중인지 확인하려면 다음 명령을 실행합니다.
kubectl describe pods pods-with-volumes
모든 것이 정상적으로 작동했다면, 출력 결과에는 각 포드에 요청된 마운트 포인트를 을 가진 my-container라는 컨테이너가 있음을 확인할 수 있습니다.
Mounts: / from my-volume (rw)
출력에는 각 포드에서 실행 중인 볼륨도 표시됩니다:
Volumes: my-volume: Type: EmptyDir(포드의 수명 주기를 공유하는 임시 디렉터리)
NetApp Cloud Volumes ONTAP을 사용한 Kubernetes 볼륨 관리
NetApp Cloud Volumes ONTAP은 업계 최고의 엔터프라이즈급 스토리지 관리 솔루션으로, AWS, Azure, Google Cloud에서 안전하고 검증된 스토리지 관리 서비스를 제공합니다. Cloud Volumes ONTAP의 용량은 페타바이트 단위로 확장 가능하며, 파일 서비스, 데이터베이스, DevOps 또는 기타 기업 워크로드 등 다양한 사용 사례를 지원합니다. 고가용성, 데이터 보호, 스토리지 효율성, Kubernetes 통합 등 강력한 기능 세트를 포함합니다.
특히 Cloud Volumes ONTAP은 컨테이너화된 워크로드의 Kubernetes 영구 볼륨 프로비저닝 및 관리 요구사항을 지원합니다.
Cloud Volumes ONTAP 사례 연구를 통해 Cloud Volumes ONTAP이 Kubernetes 워크로드에서 컨테이너화된 애플리케이션의 문제를 해결하는 데 어떻게 도움이 되는지 자세히 알아보십시오.
