[09장: 퍼시스턴트 볼륨(PV)과 퍼시스턴트 볼륨 클레임(PVC)] 9.3 PV, PVC를 이용한 볼륨 관리

[engal1991]

9.3.1 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임을 사용하는 이유

9.3.2 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임 사용하기

9.3.3 퍼시스턴트 볼륨을 선택하기 위한 조건 명시

9.3.4 퍼시스턴트 볼륨의 라이프사이클과 Reclaim Policy

9.3.5 StorageClass와 Dynamic Provisioning

[N3theri9N]

9.3.1 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임을 사용하는 이유

기존에 NFS 를 고정명시를 했기에 반드시 NFS 를 사용해야만하며, 기존 데이터를 보관하기위해 다른 네트워크 볼륨을 쓰고싶다면 YAML 를 여러 개 만들어 배포해한다. 즉 너무 밀접해서 뗄레야 뗄 수 없게되버리는 불편한 상황이 벌어진다.

이를 해소하기위해 PV PVC 를 제공한다.

• PV ; 퍼시스턴트 볼륨
• PVC 퍼시스턴트 볼륨 클레임 이 두 오브젝트는 포드가 볼륨의 세부사항을 몰라도 볼륨을 사용할 수 있도록 추상화 해주는 역할을 맡는다.

핵심은 YAML 입장에서는 네트워크 볼륨이 NFS이든, EBS이든 모른채 상관없이 볼륨을 사용하도록 하는 것이다.

• 인프라관리자 (쿠버네티스 클러스터를 관리함 ) : NFS, Ceph 와 같은 스토리지에 접근해 사용/쿠버네티스로 가져오는 역할
• 사용자 ( 개발자 ) : 디플로이먼트에 볼륨을 마운트해 사용.
• 진행시 절차
  1. 인프라 관리자는 PV 리소스를 미리 생성, 네트워크 볼륨 정보에는 NFS, iSCSI 와 같은 스토리지 서버에 마운트 하기위한 엔드포인트가 포함될 수도 있다.
  2. 사용자는 포드를 정의하는 YAML 파일 생성. '이 포드는 데이터를 영속적으로 저장해야하므로 마운트 할 수 있는 외부볼륨이 필요하다' 는 의미의 PVC 를 명시 및 생성.
  3. 쿠버네티스에서는 PV 의 속성과 PVC 의 요구사항이 일치하면 바인딩한다. 포드가 PVC 를 사용하면서 내부에 볼륨이 마운트된다.

9.3.2 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임 사용하기

kubectl get pv,pvc 명령어로 리소스 목록 출력 가능

AWS의EBS 를 예로들어보면.

1. EBS 볼륨을 생성한 다음 볼륨 ID 를 $VOLUME_ID 라는 shell 변수에 저장해둔다. 이 ID 로 PV 를 생성한다.
2. EBS 볼륨을 통해 CV의 yaml 을 생성 기존에 생성한 VOLUME_ID 내용을 여기에 사용한다.

   kind : PersistentVolume
   meatdata:
   name: ebs-pv
   spec :
   capacity : 
   storgae: 5Gi
   accessModes :
   - ReadWriteOnce
   awsElasticBlockStore :
   fsType : ext4
   volumeID : <VOLUME_ID>

   이후 PV 생성 그후 get pv 명령어 실행하면 STATUS 가 Available ( 사용 가능 ) 으로 나오게 된다.

3. PVC 를 생성한다.

   kind: PersistentVolumeClaim
   metadata :  
   name : my-ebs-pvc
   spec:
   storageClassName: ""
   accessModes:
   - ReadWriteOnce
   resources:
   requests:
       storage: 5Gi

4. 이후 포드의 volume 항목에서 my-ebs-pvc 볼륨을 마운트한다.
5. PVC 정의하는 accessModes 와 resource 항목은 볼륨의 요구사항으로 해당 조건을 만족하는 PV 와 연결된다. 5-1. 만약 요구사항의 PV가 존재하지 않다면 STATUS:pending 이 된다.
6. PVC 가 STATUS:bound 면 두 리소스가 성공적으로 연결된 상태가 된다.

9.3.3 퍼시스턴트 볼륨을 선택하기

PVC 는 특정조건을 만족하는 볼륨만을 사용해야한다는것을 쿠버네티스에 알려줄 필요가 있다. AccessMode 나 볼륨 크기 등이 조건이 해당된다. 두 속성이 부합해야만 쿠버네이트는 두 리소스를 매칭해 바인드한다. (accessMode 나 볼륨 크기는 볼륨의 메타데이터일뿐 정말 그런 속성을 가지도록 강제하진 않는다.)

예컨데 5Gi 인 PV, 3Gi 인 PV 2개가 있을시 5Gi가 필요한 PVC 는 전자의 PV 랑 마운트된다. PVC 입장에선 조건이 중요하지 어떤 것과 연결하는지는 보진 않는다.

accessMode 의 종류

• ReadWriteOnce(RWO) : 1:1 마운트만 가능, 읽기 쓰기 가능
• ReadOnlyMany(ROX) : 1:N 마운트 가능, 읽기 전용
• ReadWriteMany(RWX) : 1:N 마운트 가능, 읽기 쓰기 가능

그 외에도 스토리지 클래스나 라벨 셀렉터를 이용해 볼륨 매칭을 더 세분화 할 수 있음.

• 스토리지 클래스 : 볼륨의 대표속성, PV 생성시 클래스 설정하면 해당 클래스를 요청하는 PVC 와 바인드. storageClassName: my-ebs-volume
• 라벨 셀렉터 : 서비스와 디플로이먼트를 서로 연결할때 처럼 PVC 에 matchLabels 항목을 정의한다.

  labels:
  region: ap-northest-2a

9.3.4 퍼시스턴트 볼륨의 라이프사이클과 Reclaim Policy

PV 생성 후 kubectl get pv 명령어를 보면 STATUS 항목에 PV가 사용가능한지 연결되었는지 볼 수 있음.

• available : 사용가능
• bound : 연결됨
• Released : 바운드된 PVC 를 삭제한 후의 상태 ; 다시 사용할 수 없음. 유의점은 삭제하면 avaliable 이 예상되었으나, Released 이다. 이는 PV 의 사용이 끝났단것을 의미한다. 그렇지만 실제 데이터는 볼륨 안에 보존되어있으므로 PV 를 삭제한 뒤 다시 생성하면 available 상태로 돌아온다.

ReclaimPolicy

available 상태가 되었을때 어떻게 처리할지를 정의가 가능한데 이를 ReclaimPolicy 라고 한다. 이를 따로 정의해야하는 이유는 애초에 볼륨의 역할이 데이터의 영구저장이라서다.

ReclaimPolicy 에는 3가지 방식이 있다. (아무런 설정을 하지 않았을경우 Retain 방식)

• Retain : Available -> Bound -> Released
• Delete : PV 의 사용이 끝난 뒤에 자동으로 PV는 삭제된다. ( 연결된 외부스토리지도 함께 삭제된다. ) Available -> Bound -> ( Blank)
• Recycle : PVC 가 삭제된 후 PV 의 데이터를 모두 삭제한 뒤 Available 로 되돌린다. 볼륨의 데이터는 삭제하지만 외부 스토리지는 삭제하지 않음. 그런데 쿠버네티스에 더 이상 사용되지 않을 기능이다.

이 설정은 yaml 에서 spec : persistentVolumeReclaimPolicy : { 방식 이름} 으로 설정하며 get pv 실행시 RECLAIM POLICY 항목에 나오게된다.

9.3.5 StorageClass와 Dynamic Provisioning

다이나믹 프로비저닝은 PVC 가 요구하는 조건과 일치하는 PV 가 존재하지 않는다면 자동으로 PV 와 외부 스토리지를 함께 프로비저닝 하는 기능이다. 다이나믹 프로비저닝을 사용하면 EBS 와 같은 외부스토리지를 미리 생성할 필요가 없어진다.

특정 PV 를 선택하지 위해 스토리지 클래스를 사용했었는데 사실 스토리지 클래스는 다이나믹 프로비저닝에도 사용할 수 있는데, 스토리지 클래스의 정보를 참고해 외부 스토리지를 생성하기 때문이다.