[Kubernetes] PV(PersistentVolume), PVC(PersistentVolumeClaim)

✔️ PV, PVC

• PersistentVolume : 스토리지 볼륨 정의
• PersistentVolumeClaim : PV를 요청

 vagrant@k8s-node1  ~/volume/hostpath  kubectl api-resources | grep pv    
persistentvolumeclaims            pvc          v1                                     true         PersistentVolumeClaim
persistentvolumes                 pv           v1                                     false        PersistentVolum

pv, pvc 모두 core 그룹의 v1이며 pv는 네임스페이스를 사용하지 않아 Global하고 pvc는 네임스페이스를 사용한다.

 

✔️ PV, PVC의 철학

쿠버네티스를 설계하고 pv, pvc라는 개념을 만든 사람은 파드나 파드보다 상위 레벨의 컨트롤러는 개발자들도 잘 알고 사용할 수 있지만 아래쪽의 스토리지에 대해서는 잘 모른다고 생각했다.

 

또한 전통적인 네트워크 스토리지인 NFS, icsi, fc는 연결하고 설정하는 것이 매우 복잡하므로 개발자는 스토리지를 잘 모른다고 생각했다.

 

엔지니어는 인프라를 잘 알고 스토리지를 잘 알기 때문에 엔지니어가 스토리지를 담당하고 개발자는 파드와 컨트롤러를 담당하는 것이 좋다고 생각했다.

 

즉, 개발자와 엔지니어의 역할을 나누고 PV와 PVC라는 개념으로 기능을 분리하였다.

 

파드가 있고 스토리지가 있다고 하자
스토리지를 정의하는 리소스가 pv이며 해당 영역은 엔지니어의 영역이다.
개발자는 파드에서 바로 스토리지를 선언하는 것이 아니라 pvc라는 리소스를 만들어 연결시킨다.

pvc 리소스는 pv의 이름만을 가지고 지칭한다.

파드가 볼륨을 사용하기 위해서 pv라는 리소스와 pvc라는 리소스를 사용하게 되며 pvc는 pv를 claim(요청)한다.

 

일반적으로 파드에 스토리지를 직접 붙여 사용하는 경우는 거의 없다.

따라서 엔지니어라면 해당 구성을 잘 아는 것이 중요하다.

 

✔️ PV, PVC 사용법

 vagrant@k8s-node1  ~/volume/hostpath  kubectl explain pv.spec
 vagrant@k8s-node1  ~/volume/hostpath  kubectl explain pv.spec.hostPath

 vagrant@k8s-node1  ~/volume/hostpath  kubectl explain pvc.spec  

   selector     <Object>
     A label query over volumes to consider for binding.

   storageClassName     <string>
     Name of the StorageClass required by the claim. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#class-1

   volumeMode   <string>
     volumeMode defines what type of volume is required by the claim. Value of
     Filesystem is implied when not included in claim spec.

   volumeName   <string>
     VolumeName is the binding reference to the PersistentVolume backing this
     claim.

pvc의 목적은 pv를 가리키는 것이다. 3가지 방식이 존재한다.

 

• selector 방식을 이용하면 pvc에는 셀렉터가 있고 pv에는 레이블이 있어 셀렉터로 셀렉팅한다.
• volumeName은 pv의 이름을 지칭한다.
• storageClassName : 관리자가 제공하는 스토리지의 classes를 설명할 수 있는 방법을 제공한다.
  

 vagrant@k8s-node1  ~/volume/hostpath  kubectl explain pod.spec.containers.volumeMounts

컨테이너가 볼륨을 마운팅(volumeMounts) 해야한다.

 

 vagrant@k8s-node1  ~/volume/hostpath  kubectl explain pod.spec.volumes   

   persistentVolumeClaim        <Object>
     PersistentVolumeClaimVolumeSource represents a reference to a
     PersistentVolumeClaim in the same namespace. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

그리고 pod.spec.volumes에 persistentVolumeClaim를 선언한다.

 vagrant@k8s-node1  ~/volume/hostpath  kubectl explain pod.spec.volumes.persistentVolumeClaim

claimName : pvc의 이름이다.

이로써 알 수 있는 것은 파드는 pvc를 지칭하고 pvc는 pv를 지칭하고 pv는 실제 스토리지를 사용한다는 것이다.

 

✔️ PV, PVC 예제

Pod

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mypod
      image: httpd
      volumeMounts:
        - name: myvol
          mountPath: /tmp
  volumes:
    - name: myvol
      persistentVolumeClaim:
        name: mypvc

파드를 정의할 때 파드의 볼륨은 무조건 pvc로 정의한다.
pvc는 mypvc(pv)를 가리키고 있다.
volumes.name과 volumes.persistentVolumeClaim.name은 같아도 상관없으며 myvol을 /tmp에 마운트시킨다.

 

 

PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv # 매핑
spec:
  hostPath:
    path: /web_contents
    type: DirectoryOrCreate

 

 

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  volumeName: mypv # 매핑
  ...

pvc와 pv의 관계를 다시 정의한다.
spec.volumeName이 mypv이며 실제로 pv의 이름이 mypv이다.

 

mypv의 실제 스토리지와 관련된 부분이 spec에 들어가 있다.

최종적으로 스토리지를 사용하는 사람은 mypv의 이름만 알면 된다.

 

 

✔️ PV, PVC 생명주기

1. 프로비저닝
2. 바인딩
3. 사용
4. 회수/반환(Reclaim)
   • Retain: 보존 - PV를 삭제하지 않음(Release ← PVC가 연결 X)
   • Delete: 삭제 - PV를 삭제 / 실제 스토리지 내용 삭제
   • Recycle: 재사용(X) - 실제 스토리지 내용을 비우고, PV를 사용 가능한 상태(Available)
     
     

1. 프로비저닝
   스토리지를 만들어야 한다. pv와 연결할 스토리지를 미리 준비해야 한다.
   
   
2. 바인딩
   pv와 pvc를 만들어서 연결(Binding)해야 한다.
   
   
3. 사용
   일반적으로 바인딩하면 문제가 없는 이상 계속 사용할 수 있다.
   
   
4. 회수/반환(Reclaim)
   파드, pvc, pv, 볼륨이 있을 때 pv와 pvc의 관계를 보면 된다.
   파드가 삭제되더라도 복제본에 의해서 새로운 파드와 pvc를 연결시키면 된다.
   더이상 pv와 pvc가 필요없어 pv를 삭제한다면 pvc를 어떻게 해야하는가 ?
   어떻게 회수(Reclaim)할 것이냐 ? -> 회수 정책이 존재한다.
   
   

✔️ 회수/반환(Reclaim) 정책 

📌 pv ← 1 : 1 → pvc

pv와 pvc는 1:1 연결만이 가능하다.

pvc를 여러 파드가 연결할 수는 있다. 해당 스토리지가 네트워크 기반의 스토리지라면 문제없다.

1. Retain : 보존
   pvc를 삭제하면 pv를 그대로 둔다.
   왜 그대로 둘까 ? 혹시 pvc를 새롭게 만들어서 연결시키면 가능하지 않을까 ?
   하지만 가능하지 않다.

한번 연결됐던 pv는 기존에 연결됐던 pvc가 삭제되고 pv가 살아있더라도 다른 pvc가 연결하지 못한다.
심지어 기존에 연결됐다가 끊어진 pvc도 다시 연결하지 못한다.

2. Delete : 삭제
   pvc를 지우면 pv가 삭제된다. pv가 삭제된다는 것은 실제 스토리지가 삭제된다는 것을 의미한다.
   정확하게는 스토리지의 데이터가 삭제된다.

예를 들어 EBS 볼륨을 연결해뒀다면 EBS 볼륨은 삭제된다.
만약 클라우드 스토리지를 사용한다면 기본 반환 정책은 Delete이다.
즉, pvc를 삭제하면 pv가 삭제되는데 pv를 삭제하는 것은 스토리지를 삭제하는 것이므로 pvc를 삭제함으로써 스토리지까지 삭제하는 것이다.

3. Recycle : 재사용(X)
   pvc를 삭제하면 Retain : 보존 정책의 경우 pv의 상태가 Release 상태가 된다.
   Release는 연결 상태를 놓는다는 뜻으로 사용된다.
   이 상태에서 pvc를 다시 만들어서 연결해도 연결되지 않는다.
   pv를 재사용 하기 위해 즉, 사용이 가능한 상태로 만들기 위해서는 스토리지의 데이터를 지운다. 그리고 새롭게 비어있는 스토리지를 만들어서 pv를 재생성한다.

데이터를 삭제하는 것이 재사용이며 삭제해서 pv를 다시 사용 가능한 상태(Available)로 만들어준다.

 

왜 재사용 방식을 사용하지 않는가 ?
스토리지를 삭제하는 방법이 스토리지마다 모두 다르기 때문이다.

 

대부분 Retain(보존) 정책을 많이 사용한다.
pvc를 삭제하더라도 pv가 살아있으면 스토리지에 데이터가 살아있다는 뜻이다.
pv를 삭제하지 않는다는 것은 실제 스토리지를 삭제하지 않는다는 것이며 데이터가 남아있으므로 필요하면 Backup해서 사용할 수 있다.

pv를 남겨놓고 다른 pvc와 연결할 수 있는 것이 아니며 해당 목적으로 사용하지 않는다.

 

✔️ 접근 모드(Access Mode)

• ReadWriteOnce: RWO
• ReadWriteMany: RWX
• ReadOnlyMany: ROW

ReadWriteOnce: RWO
하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파드가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다.

ReadOnlyMany
볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다.

ReadWriteMany
볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다.

ReadWriteOncePod
볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다.

 

스토리지 유형에 따라서 지원되는 영역이 다르다.

• Block (DAS)
• Network (NAS)
  • File → Share의 기능
  • SAN

DAS와 SAN은 블록 장치를 제공하며 SAN만 네트워크를 지원한다.

블록 장치는 공유가 안된다. 대부분 Many가 안된다.
파일 스토리지, 공유의 개념을 갖는 것들은 대부분 Many가 된다.

 

NFS에는 Lock Manager가 있는데 동시에 파일에 쓰기를 못하게 한다.
동시에 쓰기를 못하도록 할 수 있어야 Sharing이 가능하다.