PV, PVC

June 7th, 2023

파드에 내용을 기록하거나 보관하거나 모든 파드가 동일한 설정값을 유지하고 관리하기 위해 공유된 볼륨으로 부터 공통된 설정을 가지고 오도록해야 하는 경우 다음과 같은 볼륨을 쿠버네티스에서 제공하고있다

임시: emptyDir
로컬: host Path, local
원격: persistentVolumeClaim, cephfs, cinder, csi, flexVolume, flocker, glusterfs, iscsi, nfs, portworxVolume, quobyte, rbd, scaleIO, storageos, vsphereVolume
특수 목적: downwardAPI, configMap, secret, azureFile, projected
클라우드: awsElasticBlockStore, azureDisk, gcePersistentDisk

이중 PV와 PVC에 대해 알아보자

쿠버네티스는 필요할 때 PVC(PersistentVolumeClaim)을 사용한다. PVC를 사용하려면 PV(PersistentVolume)을 선언해야한다. PV는 볼륨을 사용할 수 있게 준비하는 단계, PVC는 준비된 볼륨에서 일정 공간을 할당받는다.

PV도 클러스터 리소스의 일종이다. PV는 Pod와 별개의 라이프사이클을 가진다. POD가 종료되어도 PV에서 기록된 데이터는 삭제되지 않는다. PV는 NFS, ISCSI 또는 클라우드 스토리지 시스템 등에 대한 세부 정보가 있어야한다

PVC는 (PV)리소스에 대한 요청이며 리소스에 대한 클레임 검사 역할을 한다. PVC를 명시하면 쿠버네티스는 적절한 크기와 접근 모드의 PV를 찾아 PVC를 PV에 할당한다

PV, PVC 라이프사이클

프로비저닝 -> 바인딩 -> 사용중 -> 반환

정적 프로비저닝

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongodb-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  gcePersistentDisk:
    pdName: mongodb
    fsType: ext4

PV의 생성 예시다. 클러스터 관리자가 스토리지 기술을 명세해 PV를 사전에 만든다. PVC의 storage class를 지정하지 않으면 정적으로 만든 PVㄹ르 사용한다. 보통 온프레미스 환경에 활용한다

위는 capacity를 통해 용량을 명시하고 accessModes를 통해 스토리지 접근 방법을 정의한다. 그리고 실제 스토리지 유형을 명시해야하는데 여기서는 gcePersistentDisk이다

개발자는 PV리소스를 사용하겠다는 PVC를 생성한다

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: ''

여기서 storageClassName이 ““인데 이것은 미리 생성한(정적 프로비저닝) PV들에서 가능한 PV를 바인딩한다는 이야기다.

POD 볼륨에 PVC를 참조함으로서 pod에서 PV를 사용할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: mongodb
spec:
  containers:
    - image: mongo
      name: mongodb
      volumeMounts:
        - name: mongodb-data
          mountPath: /data/db
      ports:
        - containerPort: 27017
          protocol: TCP
  volumes:
    - name: mongodb-data
      persistentVolumeClaim:
        claimName: mongodb-pvc

정적 프로비저닝은 개발자가 PV의 세부정보를 몰라도 된다는 장점이 있다.

동적 프로비저닝

정적 프로비저닝의 경우 클러스터 관리자가 실제 스토리지를 미리 PV로 다 만들어야한다는 번거로운 일이있다. k8s에서는 PV의 동적 프로비저닝을 통해 이 작업을 자동으로 수행할 수 있게한다 클러스터 관리자는 PV를 생성하는 대신에, PV 프로비저너를 배포하고 사용자가 선택 가능한 하나 이상의 storage class 오브젝트를 정의할 수 있다. PVC에서 PV가 아닌 storage class를 참조하면 프로비저너가 알아서 PV를 프로비저닝 해준다

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  zone: europe-west1-b

GKE의 경우 storage class를 제공하지만 storage class를 따로 정의하고 싶다면 위와같이 작성한다

PVC는 다음과 같이 사용하면 된다

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc
spec:
  resources:
    requests:
      storage: 100Mi
  accessModes:
    - ReadWriteOnce
  storageClassName: fast

storageClassName 항목에 생성한 storage class를 명시한다. 이러면 프로비저너가 알아서 PV를 생성해주고 PVC와 연결도 해준다

바인딩

PV와 PVC가 연결되는 동작을 바인딩이라고 한다.

사용중

파드는 클레임을 볼륨으로 사용하고, 클러스터는 클레임을 검사하여 바인딩된 볼륨을 찾고 해당 볼륨을 파드에 마운트한다.

반환

볼륨을 다 사용하고 나면 리소스를 반환할 수 있는 API를 사용하여 PVC 오브젝트를 삭제할 수 있다. PVC의 반환 정책은 볼륨에서 클레임을 해제한 후 볼륨에 수행할 작업을 클러스터에 알려준다

Retain: 리소스를 수동으로 반환할 수 있게한다. PVC가 삭제되어도 PV는 여전히 존재하며 다른 요청에 대해서는 사용이 불가능하다
Delete: PV와 인프라와 관련된 스토리지 자산을 모두 삭제한다. 동적으로 프로비저닝 된 볼륨은 Storage Class의 반환 정책을 상속한다

출처

블로그

kubernetes (11)