[K8s] PV(Persistent Volume), PVC(Persistent Volume Claim)

[K8s] PV(Persistent Volume), PVC(Persistent Volume Claim)

이전에 볼륨에 관련하여 포스팅을 하면서 PV/PVC에 대해 다뤘는데, 헷갈리는 개념이 있어 더 자세히 정리해보고자 한다.

[K8s] 쿠버네티스(Kubernetes) Volume 관리

 

쿠버네티스 컨테이너 내의 디스크에 있는 파일은 임시적이며, 이는 몇가지 문제가 있다.

 

1. 컨테이너가 crash될 때 파일이 손실된다

2. pod에서 같이 실행되는 컨테이너간에 파일 공유가 어렵다.

 

이러한 문제를 모두 해결하는 방법이 볼륨이다.

기본적으로 볼륨은 디렉터리이며, 파드 내 컨테이너에서 접근할 수 있다. 

 

.spec.volumes에서 파드에 제공할 볼륨을 지정하고

.spec.containers[*].volumeMounts의 컨테이너에 해당 볼륨을 마운트 할 위치를 선언한다.

 

클러스터를 사용하는 사용자가 많을 수록 이러한 볼륨 관리가 힘든데,

쿠버네티스는 사용자 및 관리자에게 이러한 스토리지가 제공되는 방법에 대한 API를 제공한다.  

 

그 API 리소스가  PV(Persistent Volume), PVC(Persistent Volume Claim)다.

PV(Persistent Volume)

: 관리자가 프로비저닝하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 스토리지

PV는 볼륨과 같은 플러그인이지만, PV를 사용하는 개별 파드와는 다르게 라이프사이클을 가진다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

 

일반적으로 PV는 특정 저장 용량을 가지며, capactity 속성을 사용하여 설정된다.

 

PVC(Persistent Volume Claim)

: 사용자(ex. 개발자)의 스토리지에 대한 요청

PVC는 PV 리소스를 사용하며 특정 크기 및 접근 모드를 요청할 수 있다.

ex) ReadWriteOnce, ReadOnlyMany, ReadWriteMany

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

 

다음과 같이 클레임을 볼륨으로 사용해서, 파드가 스토리지에 접근할 수 있다.

클레임은 클레임을 사용하는 파드와 동일한 네임스페이스에 있어야 한다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

클러스터는 파드의 네임스페이스에서 클레임을 찾고, 이를 사용하여 클레임과 관련된 PV를 얻는다.

그 후 볼륨이 호스트와 파드에 마운트 된다.

 

PV/PVC의 생명주기

1. Provisioning (프로비저닝)

PV를 생성하는 단계로, 정적 프로비정닝과 동적 프로비저닝이 있다.

 

정적 프로비저닝

여러 PV를 만들어두고 요청이 있으면 할당한다.스토리지에 제한이 있는 경우에 유용하다.

 

동적 프로비저닝

사용자가 PVC를 거쳐서 PV를 요청했을 때 생성한다.

스토리지클래스를 기반으로 하며, PVC는 스토리지 클래스를 요청하고

관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다.

 

2. Binding (바인딩)

PV가 프로비저닝 되고 난 후 PV와 PVC를 바인딩하는 단계다.

일치하는 PV가 제공되면 PVC가 바인딩되며, 만약 없으면 무한정으로 대기한다.

 

PV와 PVC는 1:1 관계로, PVC 하나가 여러 개의 PV에 할당될 수 없다. 

 

3. Using (사용)

클러스터가 PVC를 확인하여 바인딩된 PV를 찾고 해당 볼륨을 Pod에 마운트하는 단계다.

PVC를 사용하는 Pod가 존재하면 Pod가 PVC를 사용하고 있는 상태다.

사용 중인 스토리지 오브젝트 보호
PVC에 바인딩된 Pod와 PV가 사용중인 PVC를 시스템에서 삭제되지 않도록 하는 것이다.

사용자가 파드에 활발하게 사용 중인 PVC를 삭제하면 PVC는 즉시 삭제되지 않고,
PVC가 더이상 파드에서 적극적으로 사용되지 않을 때 까지 PVC 삭제가 연기된다.

또한 관리자가 PVC에 바인딩된 PV를 삭제하면 PV는 즉시 삭제되지 않고,
PV가 더 이상 PVC에 바인딩되지 않을 때까지 PV 삭제가 연기된다.

 

4. Reclaiming (반환)

사용자가 볼륨을 다 사용한 후, PVC 리소스를 삭제 할 수 있는 단계다.

PV의 반환 정책은 볼륨에서 클레임을 해제한 후, 볼륨에 수행 할 작업을 클러스터에 알려준다.

반환 정책은 Retain, Delete가 있다.

 

Retain

리소스를 수동으로 반환할 수 있게 한다.

PVC가 삭제되면 PV는 여전히 존재하며, 볼륨은 릴리즈된 것으로 간주한다.

관리자는 다음과 같은 과정을 통해 볼륨을 수동으로 반환할 수 있다.

• PV를 삭제한다. PV가 삭제된 후에도 외부 인프라에(ex. AWS EBS) 관련 스토리지 자산이 존재한다.
• 관련 스토리지 자산의 데이터를 수동으로 삭제한다.
• 연결된 스토리지 자산을 수동으로 삭제한다.

 

Delete

PV와 외부 인프라의 관련 스토리지 자산을 모두 삭제한다.

동적으로 프로비저닝된 볼륨은 스토리지 클래스의 반환 정책을 상속한다.

관리자는 사용자의 기대에 따라 스토리지 클래스를 구성해야 한다. 

 

 

참고

https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/#%EB%B3%BC%EB%A5%A8%EC%9C%BC%EB%A1%9C-%ED%81%B4%EB%A0%88%EC%9E%84%ED%95%98%EA%B8%B0