[kubernetes] CSI(pv, pvc) 에대해 , pvc가 필요한 이유가 무엇일까?

목차

 

 

docker를 사용할때 persist volume을 사용해본 경험이 있을것이다.

 

그런데 kubernets를 사용하게되면서 pvc라는게 생겼다

 

그러다보니 pv에 pod를 연결하면 되는데 왜 굳이 pvc 를 사용하는것일까? 라는 의문이 생겼다.

 

 

pvc 를 사용하는 이유

 

MSA 구조를 적용하게 되면서 pod마다 격리되는 환경을 구성을 하게 된다.

그런데 기존의 docker에서는 하나의 서버내에서 스토리지를 공유하여 사용하는게 보통이다.

물론 외부 스토리지를 바인딩하여 사용하면 되겠지만 후술할 동적 프로비저닝이 없어서 가용성이 docker에서는 kubernetes에 비해 없다시피하다.

 

 

1. 추상화

PVC를 사용하면 개발자는 기본 인프라 세부 정보를 알 필요 없이 스토리지 리소스를 요청할 수 있으므로 애플리케이션을 더 쉽게 확장할 수 있습니다.

 

2. 동적 프로비저닝

스토리지 클래스로 구성된 경우 PVC는 사전 정의된 정책을 기반으로 스토리지 리소스를 동적으로 프로비저닝하여 프로비저닝 프로세스를 단순화할 수 있습니다.

 

3. 격리

PVC는 애플리케이션 코드에서 스토리지 관련 문제를 분리하여 애플리케이션의 유지 관리성과 이식성을 향상시킵니다.

 

 

 

추상화 의 경우는 편의상 좋은 것이 잘 이해가 되는데 2,3의 경우는 글로만 보면 이해가 안갈수 있다.

 

동적 프로비저닝의 경우 pv가 여러개 일 경우에 느껴질 것이다.

 

kubernetes에서는 pvc에는 용량 및 정책만 적고 pv 에서 연결되는 스토리지에 대한 세부 사항을 적게 된다.

 

다음은 aws efs를 persistvolume로 생성한 yaml 이다.

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-073d77123471b2917

 

Reclaim policy

• Retain -- pvc가 삭제되더라도 그대로 남겨놓기
• Recycle -- 스토리지(볼륨)은 남겨놓고 내부 파일 및 폴더 삭제
• Delete -- 스토리지(볼륨) 삭제

 

다음은 pvc 이다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

 

Accessmodes

• ReadWriteOnce: 볼륨은 동시에 하나의 노드에서만 읽기/쓰기를 허용합니다.
• ReadOnlyMany: 볼륨은 동시에 여러 노드에서 읽기 전용 모드를 허용합니다.
• ReadWriteMany: 볼륨은 동시에 여러 노드에서 읽기/쓰기를 허용합니다.

 

라벨을 적어서 매칭 시키는 방법이 있지만 accessmode와 reclaim policy, storage 용량 같은 옵션이 맞으면 자동으로 매칭하여 프로비저닝을 해주게 된다. 라벨을 적는다면 프로비저닝이 자동으로 되기 위해서 사용하려는 pv에 모두 적어야 할것이다.

 

 

 

 

 

https://vocon-it.com/2018/12/10/kubernetes-4-persistent-volumes-hello-world/

 

이 같이 동적으로 프로비저닝이 될경우 여러 pv가 있을때 굉장히 유용하다.

 

한개의 pv가 죽거나 추가해야할 경우 pv만 추가하고 pvc의 용량만 교체하면 자동으로 프로비저닝이 되기 때문이다.

혹은 물리적인 스토리지가 죽었을 경우 또다른 스토리지에 바로 프로비저닝 될것이다.

사실상 스토리지의 가용성을 굉장히 높여 준다.

 

이러한 점은 동적프로비저닝인 storage class를 지정하게 한다.

 

 

 

동적 volume: storage class

storage class를 빗대어 말하면 pv의 템플릿이라고 말할 수 있다.

 

https://www.infinidat.com/en/blog/infinidat-storage-for-kubernetes

 

storage class는 pvc에 맞게 pv를 자동으로 생성해 주는 역할을 한다.

기존의 방식으로는 프로비저너(외부스토리지나 내부스토리지)에 맞는 pv를 하나하나 생성한후 pvc와 바인딩 해야했다.

storage class는 pv를 따로 생성할 필요 없이 pvc와 storage class를 바인딩만 시켜주면 알아서 pv를 생성하여 준다.

글로만 보면 storage class를 생성하는것과 pv를 생성하는것과 차이가 없어보인다.

 

----
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-073d123fcb71b2917
  directoryPerms: "700"

 

위 storage class에서 efs같은 외부 스토리지인 경우를 예를 들면

위와 같이 한번만 생성해 놓으면 pvc에 맞는 efs의 pv를 자동으로 생성해 준다.

 

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim-1
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: efs-app-1

 

storageclassname만 맞춰서 넣어주면 자동으로 pv를 자동으로 프로비저닝 해준다.

 

 

storage class 와 다르게 pvc 마다 pv를 생성하는것에 비해 과정이 단순화 된다.

 

 

 

 

생성 순서는 storage class -> pvc -> pod 하는게 좋다.

 

 

 

Reference

https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/

Kubernetes를 위한 영구 스토리지 적용하기 | Amazon Web Services

https://medium.com/@kadimasam/kubernetes-storage-pv-pvc-and-storage-class-c107eba9c232

 

 

 

 

 

 

 

끝!