Kubernetes 볼륨의 5가지 유형 및 작업 방법

Kubernetes 볼륨이란 무엇입니까?

Kubernetes 볼륨은 Kubernetes Pod의 컨테이너에서 액세스할 수 있는 데이터가 포함된 디렉토리입니다. 디렉토리의 위치, 디렉토리를 지원하는 스토리지 미디어 및 해당 내용은 사용 중인 볼륨의 특정 유형에 따라 다릅니다.

Pod의 컨테이너 내에서 실행되는 프로세스에는 다음으로 구성된 파일 시스템 보기가 표시됩니다.

• 컨테이너 이미지의 콘텐츠와 일치하는 루트 파일 시스템입니다.
• 컨테이너에 마운트된 볼륨(정의된 경우). 각 볼륨은 컨테이너 파일 시스템 내의 특정 경로에 마운트됩니다.

볼륨은 Pod 템플릿의 .spec.containers[*].volumeMounts 필드에 정의되어 있습니다. 각 Pod 및 Pod 내의 각 컨테이너 이미지에 대해 마운트할 볼륨과 경로를 지정해야 합니다(경로는 컨테이너마다 다를 수 있음).

Kubernetes에는 몇 가지 유형의 볼륨이 있습니다. 가장 중요한 것은 Kubernetes 노드에 로컬로 저장되고 Pod가 다시 시작될 때 삭제되는 임시 볼륨과 Kubernetes 영구 볼륨 (PV)으로, Pod가 종료된 후에도 데이터를 유지합니다.

이 문서의 내용:

• Kubernetes 볼륨의 유형
  • 영구 볼륨
  • 임시 볼륨
  • EmptyDir 볼륨
  • Kubernetes hostPath 볼륨
  • 쿠버네티스 볼륨 ConfigMap
• Kubernetes 볼륨 저장을 위한 플러그인
  • NFS
  • CSI
• Kubernetes volumeMounts란 무엇입니까?
• Pod를 배포하여 Kubernetes 볼륨 생성
• NetApp Cloud Volumes ONTAP을 사용한 Kubernetes 볼륨 관리

5가지 유형의 Kubernetes 볼륨

Kubernetes는 다양한 볼륨을 지원하므로 각 Pod에서 여러 볼륨 유형을 동시에 사용할 수 있습니다. 임시 볼륨은 Pod의 수명에 바인딩되는 반면 영구 스토리지 볼륨은 Pod의 수명 이후에도 지속될 수 있습니다. 즉, Kubernetes는 Pod가 더 이상 존재하지 않으면 임시 볼륨을 삭제하는 동시에 영구 스토리지 볼륨의 데이터를 유지합니다.

영구 볼륨

Kubernetes는 스토리지 프로비저닝 및 소비를 추상화하는 API를 통해 PersistentVolume 하위 시스템을 제공합니다. 이는 두 개의 API 리소스인 PersistentVolume(PV)과 PersistentVolumeClaim(PVC)과 함께 작동합니다.

PersistentVolume (PV)
PV는 클러스터에 있는 스토리지 리소스입니다. 관리자는 PV를 수동으로 프로비저닝할 수 있으며, Kubernetes는 스토리지 클래스를 사용하여 PV를 동적으로 프로비저닝할 수 있습니다. 볼륨과 마찬가지로 PV는 플러그인이지만 수명 주기는 PV를 사용하는 Pod와 무관합니다.

PV는 iSCSI, NFS 및 클라우드 공급자 스토리지 시스템을 포함하여 스토리지 구현의 세부 정보를 캡처하는 API 객체로 작동합니다. 노드와 유사하게 작동하지만 컴퓨팅이 아닌 스토리지 리소스를 제공합니다.

PersistentVolumeClaim(PVC)
PVC는 사용자가 요청한 스토리지 요청입니다. Pod와 유사하게 작동하지만 노드 리소스가 아닌 PV 리소스를 사용합니다. PVC는 ReadWriteOnce, ReadWriteMany 및 ReadOnlyMany와 같은 크기 액세스 모드를 지정하여 특정 스토리지 리소스를 요청할 수 있습니다.

PVC를 사용하면 추상 스토리지 리소스를 사용할 수 있지만 사용자는 일반적으로 다양한 문제점에 대해 다양한 특성을 가진 PV가 필요합니다. 이 때문에 클러스터 관리자는 크기 및 액세스 모드 외에도 다양한 PV를 제공해야 하는 경우가 많습니다. StorageClass 리소스를 통해 구현 세부 정보를 사용자에게 노출하지 않고도 이를 수행할 수 있습니다.

관련 콘텐츠: Kubernetes PVC에 대한 가이드를 참조하십시오

임시 볼륨

임시 볼륨은 재시작 시 데이터를 영구적으로 저장하지 않습니다. 이러한 볼륨은 Pod의 수명에 바인딩됩니다. 즉, Pod와 함께 생성 및 삭제됩니다. 이를 통해 영구 볼륨의 가용성에 제한받지 않고 Pod를 중지하고 다시 시작할 수 있습니다.

Ephemeral 볼륨은 배포 및 관리가 간단합니다. Pod 사양에서 인라인으로 지정할 수 있습니다. Ephemeral 볼륨은 캐싱 서비스와 같이 영구 스토리지가 필요하지 않은 애플리케이션에 적합합니다.

EmptyDir 볼륨

emptyDir 볼륨은 Kubernetes가 Pod를 노드에 할당할 때 생성됩니다. 이 볼륨의 수명은 특정 노드에 존재하는 Pod의 라이프사이클과 관련이 있습니다. emptyDir 볼륨은 컨테이너가 재시작되거나 충돌할 때 다시 생성됩니다. 그러나 이 볼륨의 데이터는 Pod가 노드에서 제거되거나 충돌하거나 죽으면 삭제되고 손실됩니다.

emptyDir 볼륨을 생성한 후 포드 매니페스트 파일의 필드로 볼륨 유형 이름을 선언할 수 있습니다. 빈 중괄호{}를 값으로 하여 volume 속성 섹션 아래에 표시됩니다. EmptyDir 볼륨은 주로 임시 데이터 스토리지에 적합합니다. 예를 들어 디스크 기반 병합과 같은 스크래치 공간에 사용할 수 있습니다.

emptyDir 볼륨은 노드를 지원하는 매체에 저장할 수 있습니다. 예를 들어 네트워크 스토리지 또는 SSD를 사용할 수 있습니다. 또는 emptyDir.medium 필드에 "memory"를 설정하면 Kubernetes가 RAM 기반 파일 시스템(tmpfs)을 마운트합니다. Kubernetes는 노드 재부팅 시 tmpfs를 지웁니다.

Kubernetes hostPath 볼륨

hostPath 볼륨은 호스트 노드의 파일 시스템에 있는 디렉토리 또는 파일을 Pod에 마운트합니다.

다음은 hostPath 볼륨의 주요 사용 사례입니다.

• /var/lib/dockerhostPath—를 사용하여 Docker 내부에 액세스해야 하는 컨테이너를 실행합니다.
• /sys hostPath—를 사용하여 컨테이너에서 cAdvisor를 실행합니다.
• Pod가 hostPath를 지정할 수 있도록 허용합니다—특정 hostPath가 Pod 실행 전에 존재해야 하는지 여부와 생성해야 하는지 여부를 정의합니다.
• hostPath 볼륨의 유형 지정—필수 경로 속성 외에 이를 설정할 수 있습니다.

HostPath 볼륨 보안
HostPath 볼륨은 많은 보안 위험을 초래합니다. 가능하면 이러한 볼륨을 사용하지 마십시오. HostPath 볼륨을 사용해야 하는 경우 필요한 디렉토리 또는 파일로만 범위를 지정하고 ReadOnly로 마운트해야 합니다.

주요 보안 위험은 다음과 같습니다.

• 노출된 자격 증명—HostPaths는 권한 있는 시스템 자격 증명 또는 권한 있는 API를 노출할 수 있습니다. 위협 행위자는 이를 사용하여 클러스터의 다른 부분을 공격하거나 컨테이너 탈출에 사용할 수 있습니다.
• 루트 권한—기본 호스트에서 생성된 모든 디렉토리 또는 파일은 루트만 쓸 수 있습니다. hostPath 볼륨에 쓰려면 호스트에서 파일 권한을 수정하거나 권한이 있는 컨테이너 내에서 프로세스를 루트로 실행해야 합니다.

AdmissionPolicy를 사용하여 특정 디렉토리에 대한 HostPath 액세스를 제한할 수 있습니다. 그러나 이 정책은 volumeMounts가 readOnly 마운트를 사용하도록 요구하는 경우에만 유효합니다.

쿠버네티스 볼륨 ConfigMap

ConfigMap을 사용하면 구성 데이터를 Pod에 주입할 수 있습니다. ConfigMap 내에 저장된 데이터는 configMap 볼륨 타입에서 참조할 수 있으며 Pod에서 실행되는 컨테이너화된 애플리케이션에서 사용할 수 있습니다. ConfigMap을 참조할 때 볼륨에 ConfigMap의 이름을 제공해야 합니다. Kubernetes를 사용하면 ConfigMap의 특정 항목에 대한 경로를 사용자 지정할 수 있습니다.

Kubernetes 볼륨 저장을 위한 플러그인

Kubernetes는 Kubernetes 클러스터에 배포된 스토리지 장치에 대한 액세스를 제공하는 여러 스토리지 플러그인을 제공합니다. 이는 StorageClass 오브젝트를 사용하여 구현됩니다.

현재 Kubernetes에서 지원하는 주요 플러그인으로는 GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS, iSCSI가 있습니다. 이러한 플러그인에 대한 자세한 내용은 StorageClass 설명서를 참조하십시오.

두 가지 주목할만한 스토리지 플러그인을 더 자세히 검토해 보겠습니다.

NFS

Network File System(NFS)은 스토리지 디바이스를 로컬 드라이브로 마운트하기 위한 표준 프로토콜입니다. Kubernetes를 사용하면 NFS 볼륨을 컨테이너의 로컬 드라이브로 마운트할 수 있습니다. 레거시 코드는 NFS를 통해 데이터에 액세스하는 경우가 많기 때문에 이 플러그인은 레거시 워크로드를 Kubernetes로 마이그레이션하는 데 매우 유용합니다.

NFS와 Kubernetes를 통해 데이터에 액세스하는 방법에는 두 가지가 있습니다.

• 사용 후 삭제 NFS 볼륨—기존 NFS 스토리지에 연결할 수 있습니다.
• PersistentVolumes with NFS—NFS를 통해 액세스되는 클러스터에 관리형 리소스를 설정할 수 있습니다.

CSI

Container Storage Interface(CSI)는 컨테이너 오케스트레이터가 관리하는 컨테이너에 스토리지 시스템을 노출할 수 있도록 하는 표준 인터페이스입니다. CSI를 사용하면 스토리지 공급업체가 "out of tree" 플러그인을 생성할 수 있으며, 이는 Kubernetes 코드 리포지토리에 체크인할 필요가 없고 Kubernetes와 함께 제공되지 않음을 의미합니다.

스토리지 공급업체에서 직접 제공하는 CSI 기반 out of tree 플러그인이 많이 있습니다. CSI의 출현으로 스토리지 기술이 Kubernetes를 훨씬 더 쉽게 지원할 수 있게 되었습니다.

관련 컨텐츠: Container Storage Interface 가이드 읽기

Kubernetes volumeMounts란 무엇입니까?

볼륨을 생성하고 Pod에서 액세스할 수 있도록 하는 데는 두 가지 단계가 포함됩니다.

• Pod 템플릿의 spec:volumes 속성에서 선언한 다음 일부 노드에 Pod를 배포합니다
• spec:containers::volumeMounts 속성을 사용하여 특정 컨테이너에 볼륨 마운트

이 단계는 서로 밀접한 관련이 있습니다. 볼륨을 생성할 때 컨테이너에도 마운트해야 하며, Pod 템플릿에서 선언하지 않고는 볼륨을 마운트할 수 없습니다.

다음은 Pod 템플릿 YAML 구성에서 볼륨 생성 및 마운트를 모두 보여주는 예입니다.

spec: containers: —name: my-app image: nginx volumeMounts: —name: my-volume mountPath: /app/config volumes: —name: my-volume 

이 코드에서:

• volumes(맨 아래)는 my-volume 이라는 볼륨을 생성하여 Pod에 연결합니다
• volumeMounts는 컨테이너 내부에서 볼륨을 사용할 수 있는 파일 경로를 포함하여 볼륨이 마운트되는 방법을 정의합니다
• 두 위치(볼륨 선언 및 volumeMounts 속성)에서 동일한 볼륨 이름을 사용해야 합니다.

Pod를 배포하여 Kubernetes 볼륨 생성

Kubernetes 볼륨을 생성하려면 볼륨을 선언하는 하나 이상의 Pod를 배포합니다. 이 작업을 수행하는 일반적인 방법은 Deployment 개체를 사용하는 것입니다. 다음을 수행하는 Deployment 매니페스트의 예는 다음과 같습니다.

• 각각 1개의 NGINX 컨테이너가 포함된 3개의 Pod 배포
• 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: {} 

이 배포의 이름은 pods-with-volumes에 정의되어 있으며, 이는 Kubernetes 환경에서 참조하는 방법입니다.

이전 섹션에서 살펴본 것처럼 이 Deployment 오브젝트는 볼륨을 생성하는 데 필요한 두 가지 작업을 수행합니다.

• spec:template:volumes 속성은 볼륨을 선언합니다.
• spec:containers::volumeMounts 속성은 볼륨을 컨테이너에 마운트합니다.

이 YAML 파일이 my-deployment.yaml이라는 이름으로 저장되었다고 가정해 보겠습니다. 다음 명령을 사용하여 Kubernetes 클러스터에서 Deployment를 생성할 수 있습니다.

kubectl apply -f my-deployment.yaml

배포가 예상 볼륨으로 올바르게 실행되고 있는지 확인하려면 다음 명령을 실행합니다.

kubectl describe pods pods-with-volumes

모든 것이 올바르게 작동하면 출력에 각 Pod에 요청된 마운트 지점이 있는 my-container라는 컨테이너가 있음을 알 수 있습니다.

마운트: my-volume에서 /(rw)

출력에는 각 Pod에서 실행 중인 볼륨도 표시됩니다.

Volumes: my-volume: Type: EmptyDir (Pod의 수명을 공유하는 임시 디렉터리)

NetApp Cloud Volumes ONTAP을 사용한 Kubernetes 볼륨 관리

NetApp Cloud Volumes ONTAP은 업계 최고의 엔터프라이즈급 스토리지 관리 솔루션으로, AWS, Azure, Google Cloud에서 안전하고 검증된 스토리지 관리 서비스를 제공합니다. Cloud Volumes ONTAP 용량은 페타바이트 단위로 확장할 수 있으며 파일 서비스, 데이터베이스, DevOps 또는 기타 엔터프라이즈 워크로드와 같은 다양한 사용 사례를 지원하고 고가용성, 데이터 보호, 스토리지 효율성, Kubernetes 통합 등을 비롯한 강력한 기능 세트를 제공합니다.

특히 Cloud Volumes ONTAP은 컨테이너화된 워크로드의 Kubernetes 영구 볼륨 프로비저닝 및 관리  요구사항을 지원합니다.

이러한 Kubernetes 워크로드와 Cloud Volumes ONTAP 사례 연구에서 Cloud Volumes ONTAP이 컨테이너화된 애플리케이션의 과제를 해결하는 데 어떻게 도움이 되는지 자세히 알아보십시오.