이 페이지에는 기계 번역이 사용되었습니다. 일부 콘텐츠는 완벽하지 않을 수 있습니다.

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

이 페이지 공유하기

Yifat Perry

2022-06-12

Kubernetes 볼륨이란 무엇인가요?

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

파드 내 컨테이너에서 실행되는 프로세스는 다음과 같은 파일 시스템 뷰를 보게 됩니다:

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

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

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

이 문서의 내용:

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

5가지 유형의 Kubernetes 볼륨

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

영구 볼륨

Kubernetes는 스토리지 프로비저닝 및 사용을 추상화하는 API를 갖춘 PersistentVolume 서브시스템을 제공합니다. 이 서브시스템은 PersistentVolume(PV) 및 PersistentVolumeClaim(PVC)이라는 두 가지 API 리소스를 사용합니다.

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

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

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

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

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

임시 볼륨

임시 볼륨은 재시작 시 데이터를 영구적으로 저장하지 않습니다. 이러한 볼륨은 파드의 수명에 따라 생성되고 파드와 함께 삭제됩니다. 따라서 영구 볼륨의 가용성에 구애받지 않고 파드를 중지하고 재시작할 수 있습니다.

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

EmptyDir 볼륨

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

emptyDir 볼륨을 생성한 후에는 Pod 매니페스트 파일에서 해당 볼륨 유형 이름을 필드로 선언할 수 있습니다. 값은 빈 중괄호{}로 표시된 볼륨 속성 섹션에 나타납니다. EmptyDir 볼륨은 주로 임시 데이터 저장에 적합합니다. 예를 들어 디스크 기반 병합과 같은 스크래치 공간으로 사용할 수 있습니다.

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

Kubernetes hostPath 볼륨

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

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

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

HostPath 볼륨 보안
HostPath 볼륨은 많은 보안 위험을 내포하고 있습니다. 가능한 한 이러한 볼륨 사용을 피하십시오. HostPath 볼륨을 반드시 사용해야 하는 경우, 필요한 디렉터리 또는 파일로만 범위를 지정하고 ReadOnly로 마운트해야 합니다.

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

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

AdmissionPolicy를 사용하여 HostPath의 특정 디렉터리 접근을 제한할 수 있습니다. 단, 이 정책은 volumeMounts가 readOnly 마운트를 사용하도록 요구하는 경우에만 유효합니다.

Kubernetes 볼륨 ConfigMap

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

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

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

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

주목할 만한 스토리지 플러그인 두 가지를 좀 더 자세히 살펴보겠습니다.

NFS

NFS(네트워크 파일 시스템)는 스토리지 장치를 로컬 드라이브로 마운트하기 위한 표준 프로토콜입니다. Kubernetes를 사용하면 NFS 볼륨을 컨테이너의 로컬 드라이브로 마운트할 수 있습니다. 기존 코드는 종종 NFS를 통해 데이터에 접근하기 때문에, 이 플러그인은 기존 워크로드를 Kubernetes로 마이그레이션하는 데 매우 유용합니다.

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

임시 NFS 볼륨—기존 NFS 스토리지에 연결할 수 있습니다.
PersistentVolumes와 NFS—NFS를 통해 액세스되는 관리형 리소스를 클러스터에 설정할 수 있습니다.

CSI

컨테이너 스토리지 인터페이스(CSI)는 컨테이너 오케스트레이터가 관리하는 컨테이너에 스토리지 시스템을 노출할 수 있도록 하는 표준 인터페이스입니다. CSI를 통해 스토리지 공급업체는 Kubernetes 코드 저장소에 커밋할 필요가 없고 Kubernetes에 포함되지 않는 "트리 외부" 플러그인을 만들 수 있습니다.

스토리지 벤더들이 직접 제공하는 CSI 기반의 트리 외부 플러그인이 많이 있습니다. CSI의 등장으로 스토리지 기술이 Kubernetes를 지원하는 것이 훨씬 쉬워졌습니다.

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

Kubernetes volumeMounts란 무엇입니까?

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

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

이 단계들은 서로 밀접하게 연관되어 있습니다. 볼륨을 생성할 때는 반드시 컨테이너에 마운트해야 하며, 파드 템플릿에 볼륨을 선언하지 않고는 마운트할 수 없습니다.

다음은 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 매니페스트의 예입니다:

각각 하나의 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: {}

이 Deployment의 이름은 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

모든 것이 정상적으로 작동했다면 출력 결과에는 각 파드에 요청된 마운트 지점을 가진 my-container라는 이름의 컨테이너가 있는 것으로 표시될 것입니다.

마운트:
 / from my-volume (rw)

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

볼륨:
 my-volume:
 유형: 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 워크로드에서 컨테이너화된 애플리케이션의 문제를 해결하는 데 어떻게 도움이 되는지 자세히 알아보세요.