Kubernetes Storage

Kubernetes storage에는 대표적으로 Persistent Volume, Persistent Volume Claim, StorageClass 가 있다.

1. Persistent Volume (PV)

Cluster 내에서 사용 가능한 실제 스토리지를 추상화한 Resource 이다. 로컬 디스크, 네트워크 파일 ,NFS, 클라우드 스토리지와 같은 실제 물리 / 가상 스토리지 자원을 Kubernetes 내부에서 일관된 방식으로 다룰 수 있다.

Kubernetes Pod은 기본적으로 휘발성 스토리지를 사용한다. Pod 이 재시작되면 데이터가 사라진다. 하지만 DB나 FileServer 처럼 데이터를 영구적으로 저장해야하는 Application의 경우 Pod lifecycle과 독립적으로 데이터를 보존할 수 있는 Storage가 필요하다.

Persistent Volume은 데이터의 영구적인 속성을 제공하기 위한 개념으로 Pod 이 Persistent Volume Claim(PVC)를 통해 필요 시점에 Volume을 청구(Claim)하고 사용할 수 있도록하는 구조이다.

PV는 스토리지 관리자 수동으로 만들어둘 수도 있고 StorageClass 를 통해 동적 프로비저닝도 가능하다.

 

NFS 기반 PV 예시

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /data
    server: 10.0.0.100
  persistentVolumeReclaimPolicy: Retain

1) capacity

storage: pv 가 제공하는 스토리지 용량

위에는 10GI가 설정되어있으며 일반적으로 PVC가 이보다 작거나 같은 용량을 요구해야 바인딩이 가능하다.

2) accessmodes

pv 및 pvc에서 정의할 수 있는 스토리지 접근 모드

 

• ReadWriteOnce (RWO): 오직 하나의 노드에서만 읽기/쓰기가 가능.
• ReadWriteMany (RWX): 여러 노드에서 동시에 읽기/쓰기가 가능.
• ReadOnlyMany (ROX): 여러 노드에서 읽기만 동시에 가능.

ReadWriteMany 는 NFS, GlusterFS, CephFS 같은 분산 파일 시스템에서 지원하며 여러 Pod를 동시에 마운트해도 문제는 없다

하지만 EBS /GCE PD 같은 Block Storage 는 주로 RWO 만 지원한다.

3) Stroage type setting

예를 들어 

NFS의 경우 nfs.server, nfs.path 가 필요하다

AWS EBS의 경우 awsElasticBlockStore: volumeID, fsType 등을 설정해야한다

GCE PD의 경우 gcePersistenDisk :pdName, fsType 등을 설정한다

위와 같이 PV의 구체적인 스토리지 설정은 해당 Volume Type에 따라 달라진다.

4) persistenVolumeReclaimPolicy

pv가 사용(Bind)된 후 PVC가 삭제되거나 Volume 사용이 끝났을 때 이 PV를 어떻게 처리할 지 결정한다.

- Retain : 데이터와 PV Object를 그대로 남겨둔다 ( 관리자가 나중에 직접 삭제하거나 재활용할 수 있다)

- Recycle : 과거 버전에서 사용했던 방법으로 PV 내부 파일을 삭제 후 PV를 재사용하는 방식이다.

- Delete : PVC가 삭제되면 실제 Backend Storage Resource (EBS, GCE PD 등) 도 함깨 삭제한다.

NFS 기반으로는 대개 Retain을 많이 쓰며, 클라우드 블록 스토리지(EBS, GCE PD)는 Delete를 기본값으로 쓰는 경우가 많다

 

1.2 PV Provisioning 방식

1) Static Provisioning

관리자가 PersistenVolume Resource를 수동으로 만든다.

PVC가 생성되면 Kubernetes는 조건에 맞는 PV를 찾아서 Binding 한다. 

2) Dynamic Provisioning

관리자 또는 Cloud 환경에서 StorageClass 를 정의한다. PVC 에서 해당 StorageClass를 지정하면 Kubernetes 가 자동으로 PV (Backend Sotrage Resource)를 생성해준다.

예를들어 AWS EBS 에서는 StorageClass 를 통해 자동으로 디스크를 할당 받을 수 있다.

 

Static Provisioning 은관리자가 직접 PV를 만들고 PVC가 조건에 맞는 PV를 사용하는 방식이라면 

Dynamic Provisioning 은 PVC에 맞춰서 StorageClass가 자동으로 PV를 생성하는 방식이다.

 

PV가 사용되는 흐름

1) 관리자가 Static Provisioning or Dynamic Provision 중 하나를 수행

2) User 가 PVC를 생성한다

예를들어 용량 5GI, RWX 라고 선언하면

3) Kubernetes가 PVC 조건에 맞는 PV(10Gi, RWX 지원)을 찾아서 바인딩한다.

바인딩되면 PVC는 Bound 상태가 되고 PV는 해당 PVC와 연결된다.

4) Pod 에서 PVC를 Mount

Pod가 배포될 때 PVC를 통해 PV에 접근이 가능하게 된다

5) PVC가 삭제되면 Reclaim Policy 에 따라

Retain인 경우 PV 및 데이터가 남고

Delete인 경우 Backend Storage까지 삭제한다.

 

2. PVC (Persistent Volume Claim)

개발자/사용자가 필요로 하는 스토리지 요구사항을 선언하는 객체이다.

그렇다면 PVC는 왜 필요할까? PVC를 사용함으로써 스토리지 요구사항을 추상화시킬 수 있다. 구체적인 Storage type 이나 setting은 PV 또는 StorageClass가 담당하기 때문에 PVC는 단순한 인터페이스처럼 이용할 수 있다.

그리고 애플리케이션과 스토리지를 분리할 수 있다. PVC 는 Pod와 PV를 간접적으로 연결한다. 이를 통해 Storage 변경 시에 Pod 스펙은 PVC 참조만 바꾸거나 그대로 유지하는 운영적 편의성을 가진다.

 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: ""  # 혹은 특정 StorageClass

spec.resources.requests.storage : pvc가 필요하는 용량이다.

""(빈 문자열)이나 생략 시 → 아무 StorageClass도 사용하지 않고, 기존 정적 PV 중에서 매칭한다.

특정 StorageClass 이름 (ex. "gp2", "nfs-storage")을 지정 시 → 동적 프로비저너가 새로운 PV를 자동 생성한다

Kubernetes Cluster에 Default StorageClass 가 설정되어있으면 storageClassName을 적지 않아도 자동으로 해당 클래스가 사용될 수 있다.

 

3. StorageClass

Dynamic Provisioning 을 지원하기 위해 필요한 설정이다

클라우드(예: AWS EBS, GCE PD, Azure Disk)나 On-Prem CSI 플러그인을 통해 자동으로 디스크를 할당한다.

 

예시: AWS EBS StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp2
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

volumeBindingMode: WaitForFirstConsumer → 실제 스케줄링될 Node가 정해지기 전까진 PV 생성 지연된다 → 최적화된 AZ 선택 가능하다.