[Kubernetes] 쿠버네티스 볼륨 개념 2편 (pv, pvc, AWS EBS, AWS EFS )

ㅁ 이전 글

[EBS] EKS 생성, MongoDB 구성, gp2에서 gp3 EBS 볼륨으로 마이그레이션

[Kubernetes] 쿠버네티스 볼륨 개념 1편 (emptryDir, hostPath)

 

 일전 StorageClass 변경에 관한 글을 작성하면서 AWS 볼륨과 PV, PVC 관계이해 정리한 적이 있다. 그래도 복잡했다. 실제 볼륨의 증설 작업을 하면서 pvc에 스토리지 용량을 변경해야하는지 pv의 스토리지 용량을 변경해야하는 지 헷갈리기도 했는데, 문득 궁금하였다.  왜 pv와 pvc를 구분하여 복잡하게 했을까? 그래서 공부하다가 이해한 부분을 이 글로 정리하게 되었다.

 쿠버네티스 환경에서는 데이터의 안정적인 저장을 위해 볼륨을 Pod에 할당하지 않고  AWS 볼륨, PV와 PVC로의 연결, 마지막 Pod에 마운트 해서 쓰는 이유와 의미를 공부해 보았다.

 이해를 위한 키워드는 스토리에 대한 총괄적 관리자서 AWS 어드민 관리자와 사용자 입장에서의 DevOps 개발자의 관계성이며, 이 관계성을 이해하고 스토리지 리소스를 효율적으로 관리하기 위한 방법이 무엇일지를 반문하며 접근하는 것이 이해에 도움이 되었다. 비유적으로 설명하면, PV는 스토리지인 USB자체이며, PVC는 맥에서 필요한 용량에 따라 파티션을 걸어 포맷하여 사용할 때에 마운트 된 상태 그 자체를 정의하는 것이다.

 

ㅁ Persistent Volume(PV)이란?

 Persistent Volume는 말자체로 영구적인 볼륨 자체를 뜻한다. 클러스터 안에서 하나의 자원으로 인식되어 파드와 별개로 관리되며, 별도의 생명 주기를 가진다. 예를 들어 관리자에 의해 AWS에서 영구적인 볼륨 EBS를 생성한 후에, 이 저장 매체를 PersistentVolume이라는 자원으로 쿠버네티스에 등록시키는 것이다. 기억을 위해 간단히 정리하면, PV는 관리자가 만든 실질적인 볼륨 자체를 뜻하고, 쿠버네티스 입장에서는 볼륨에 대한 자원으로서의 인식을 위한 영구 스토리지 볼륨 객체이다. 쿠버네티스에서 객체(오브젝트)는 네임스페이스에 종속하지 않는다. 그래서 PV는 네임스페이스에 종속하지 않고 클러스터에 종속되며, 다른 네임스페이스에서 접근이 가능하다.

 

 PV의 읽기/쓰기 옵션을 설정하는 3가지 accessModes가 있다. 

 ㅇ ReadWriteOnce: 노드 하나에만 읽기쓰기 가능

 ㅇ ReadOnlyMany:  여러 개 노드에 읽기 전용

 ㅇ ReadWriteMany: 여러 개 노드에 읽기쓰기 가능

 

https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/

 이는 지원하는 볼륨에 따라서 전체 옵션을 선택적으로 사용 가능하다.

 

 

ㅁ PersistentVolumeClaim(PVC)란?

  PersistentVolumeClaim는 말자체로 영구 볼륨 요청을 뜻한다. PVC는 사용자(DevOps 개발자)가 PV에  사용을 요청하는 것이다.  사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등 구체적으로 어떻게 사용할 지에 대한  요청을 정의한다. 비유적으로 설명하면, PV는 USB자체이며, PVC는 맥에서 사용할 때에 그에 맞는 포멧 형식으로 포멧이 되어 있는 상태 그 자체를 정의하는 것이다. 이 쿠버네티스는 볼륨을 파드에 직접 마운트하지 않고 중간에 PVC를 두어 파드가 볼륨을 사용할 때에 시스템적인 제약사항을 두고 있다. 이전 제약을 통해 상황에 맞게 다양한 스토리지를 사용할 수 있게 한다. 

 

 

ㅁ AWS 볼륨과 PV, PVC 관계이해

  먼저 AWS 볼륨이 생성되고 쿠버네티스 API서버로 PV를 생성해 쿠버네티스에 등록한다. PV가 생성되면 크기와 지원 가능한 접근 모드를 지정해야 하는데,  먼저 최소 용량과 접근 모드를 명시한 PVC 생성한다. 그런 다음 PVC를 쿠버네티스 API 서버에 게시하고 쿠버네티스는 적절한 PV를 찾아 클레임에 볼륨을 바인딩한다. 그리하여 최종적으로 PVC는 POD 내부의 볼륨 중 하나로 사용될 수 있다. AWS 볼륨 -> PV -> PVC 순으로 생성되는 것이다. PVC는 namespace로 나뉘어 관리되지만, PV는 Cluster에 종속되기 때문에 namespace에 종속되지 않고 공용으로 사용할 수 있다. PV와 PVC는 일대일로 연결되어진다. 다만 이 설명은 AWS EBS에 대한 것이다. 

 

 

ㅁ PV와 PVC의 생명주기

  볼륨은 생명주기를 가지고 있다. 프로비저닝, 바인딩, 사용, 반환의 사이클로 볼륨의 생명주기를 가지고 있다. 이해를 위해 비유적으로 표현하면, 관리자가 USB를 구매(프로비저닝)하고, 맥사용자를 위해 포맷(바인딩)을 하여, 맥에서 사용하다가, 반환을 하는 것이다.

 

 

ㅁ 프로비저닝, 동적, 정적의 의미

 먼저 PV를 만드는 것을 프로비저닝(생성, Provisioning)이라고 말한다. 만들 대에 미리 만들어 두어 정의해 놓은 상태를 정적 프로비저닝이라 하고, PVC 요청이 들어왔는데 실제로 여기에 맞는 PV가 없으면 그 때에 PV를 생성하는 것이 동적 프로비저닝이라고 한다. 

 

 정적으로 PV를 프로비저닝할 때는 클러스터 관리자가 미리 적정 용량의 PV를 만들어 두고 사용자의 요청이 있으면 미리 만들어둔 PV를 할당한다. 사용할 수 있는 스토리지 용량에 제한이 있을 때 유용합니다. 사용하도록 미리 만들어둔 PV의 용량이 100GB라면 150GB를 사용하려는 요청들은 실패한다. 1TB 스토리지를 사용하더라도 미리 만들어둔 PV 용량이 150GB 이상인 것이 없으면 요청이 실패한다.

  동적으로 프로비저닝할 때는 사용자가 PVC를 거쳐서 PV를 요청했을 때 생성해 제공한다. 쿠버네티스 클러스터에 사용할 1TB 스토리지가 있다면 사용자가 필요할 때 원하는 용량만큼을 생성해서 사용할 수 있다. 정적 프로비저닝과 달리 필요하다면 한번에 200GB PV도 만들어 사용할 수 있다. PVC는 동적 프로비저닝할 때 여러 가지 스토리지 중 원하는 스토리지를 정의하는 스토리지 클래스(StorageClass)로 PV를 생성한다.(쿠버네티스 입문, 동양북스, 339쪽)

 

 

ㅁ 바인딩

  PV를 PVC에 연결시키는 단계이다. 사용자가 필요한 볼륨을 PVC로 생성하여 관리자에게 요청하면 그에 맞는 PV 볼륨이 있으면 할당해주고 없으면 동적 프로비저닝하여 연결시켜 준다. 관리자 입장에서 볼륨이 무한이 아니기 때문에 PVC(요청)에 맞는 PV(볼륨)이 없으면 한번 실패로 끝나는 것이 아니라 기존 사용하던 PV가 반납되거나 새롭게 PV를 생성하게 되면 PVC에게 바인딩할 수 있다. 왜냐하면 PV는 공용으로 사용하지 못하고 하나의 PVC(요청)에 하나의 PV(볼륨)이 제공되기 때문이다. 관리자의 입장에서 제한된 자원을 요청에 맞추어 분할해서 PV를 생성하여 제공하고 더 나아가 필요한 볼륨을 증설하여 PVC에 대응하기 위해 PV, PVC의 개념이 필요하다.

 

 

ㅁ 사용

  PVC의 할당된 PV를 통해 파드는 볼륨으로 인식하여 영구 저장되는 데이터 스토리지로 사용하게 된다. 할당된 PVC는 파드를 유지하는 동안 계속 사용하며 시스템에서 임의로 삭제 할 수 있도록 유지된다. 우리가 노트북에 USB를 임의로 제거하려 할 때에 데이터 복사 중이면 제거가 되지 않는 것처럼 데이터 보호를 위한 일종의 안전장치이다. 

  Finalizers를 보면, [kubernetes.io/pv-protection] 라는 메시지를 확인 할 수 있는데, 이것이 사용 중인 스토리지를 보호한다는 의미이다. source에서 보면 AWS EBS가 클러스터에 pvc-8d2bad4c-8835-4145-ba85-c1045a1921d8 오브젝트로 인식되어 있고 클러스터에 종속된 객체이기에 namespace에 대한 정의는 없다.

 

 

ㅁ 반환

 사용이 끝난 PVC는 삭제되고 PV는 초기화 하게 된다. 이를 반환이라고 하며, 초기화 방식에는 Retain, Delete, Recycle이 있다.

 Retain은 PV를 그대로 둔다. PVC(요청)이 더이상 필요가 없게 되면 PV는 연결 해제 상태가 된다. 이럴 때에는 관리자가 PV를 재사용하기 위해 초기화를 해 줘야한다. 예를 들어, 위의 PV는 현재 status가 bound로 PVC와 연결된 상태이지만 내가 PVC를 삭제하면 PV는 남겨지고 실질적인 데이터는 AWS EBS volumeID에 남아있기 때문에 이 데이터를 보호하기 위해 직접 초기화 해야한다. 일단 PV를 삭제하여 클러스터와의 연결을 끊고, AWS EBS 남은 데이터를 백업하던 삭제를 한다. 그리고 EBS를 다시 PV로 클러스터에 다시 연결해야 재사용을 할 수 있다.
  EBS 재사용 방법에 대해서는 시간이 되면  다시 공부를 해야할 것 같다. 히스토리를 위해 볼륨에 데이터를 저장하고 있는데, 현재 운영에서 POD 형태로 띄어 쓰고 있는 몽고디비가 EKS 버젼업이나 신규 테스트 클러스터를 구성하면서 신규로 생성 될 때에 기존 볼륨을 재사용하지 못하고 신규로 생성해서 쓰고 있기 때문이다. 신규로 생성만 해보았지, 재사용에 대해서는 시도해 보지 않았던 부분이라 그래서 추후에 공부를 해 보면 좋을 것 같다.

 

Delete는 PV를 삭제하고 연결된 외부 스토리지 쪽의 볼륨도 삭제한다. 동적 프로비저닝 된 경우 PV의 기본 반환 정책(Reclaim Policy)은 Delete이다. 위의 PV도 동적으로 프로비저닝 되어 Delete임을 확인 할 수 있다. 상황에 따라 데이터의 보존이 필요하고 재사용이 필요하면 반환 정책을 변경해야한다.

 

Recycle은  PV의 데이터들을 삭제하고 다시 새로운 PVC에서 PV를 사용할 수 있게 한다. 

 

 

 

ㅁ AWS EFS 

 현재 사용하고 있는 AWS 환경 기준으로 EBS와 EFS의 간략한 차이를 이해해야한다.  EBS의 경우 accessModes가 노드 하나에만 읽기쓰기 가능만 지원된다. 그 이유는 EBS 볼륨은 Available Zone(가용영역)에 속하는 스토리지이기 때문에 가용영역을 넘어서는 노드에는 공유할 수 없다. 그래서 쿠버네티스 환경에서 동적으로 할당되는 pod가 어느 가용영역에 속할 지 모르기 때문에 EBS의 경우 하나의 노드에만 볼륨을 마운트 할 수 있다. 이를 넘어서는 것이 EFS이다.  EFS의 위치는 VPC안에 속해 있지만  AZ과 별개로  넘어서 VPC 안에 속해 있다. 

  AWS EKS에서 EFS를 사용하기 위해서는 EFS CSI(Container Storage Interface) 드라이버가 설치되어야 하고, 마운트하고자 하는 WorkNode들은 EFS를 접근할 수 있는 AmazonElasticFileSystemFullAccess  권한을 가지고 있어야 한다.

 

 

ㅁ [EKS] AWS EKS에 EFS 연동하기

다음 글 : [EKS] AWS EKS에 EFS 연동하기

 

ㅁ 함께 보면 좋은 사이트

볼륨

 ㅇ 쿠버네트스 개념 문서 > 스토리지 > 볼륨

 

암호화된 Amazon EFS 파일 시스템을 Amazon EKS 포드에 마운트

 ㅇ EKS에서 EFS 파일시스템 마운트하기

 

http://www.yes24.com/Product/Goods/85578606

쿠버네티스 입문 - YES24

 ㅇ 쿠버네티스 입문 책