Docker Storage
Storage Driver
- Docker는 레이어드 아키텍처(이미지/컨테이너 레이어 구조)를 구현하기 위해 Storage Driver를 사용한다.
- Storage Driver는 Docker 이미지와 컨테이너의 저장소를 관리한다.
- Storage Driver는 종류가 다양한데 Docker는 OS 환경을 보고 사용 가능한 Storage Driver중 가장 적절한 것을 자동으로 선택한다. (수동 선택도 가능)
Volume
- 컨테이너가 종료되어도 데이터를 유지하려면 Volume을 생성해야한다. (Volume은 Storage Driver가 관리하지 않는다.)
- Volume은 Volume Driver에 의해 관리되는데, 하나의 Volume Driver는 여러 Cloud/Storage Privder를 지원한다.
- AWS(EBS, S3), Google Persistent Disk, OpenStack Cinder 등
- 컨테이너 실행시 특정 Volume Driver 선택이 가능하다.
Container Storage Interface(CSI)
- CSI(Storage), CNI(Network), CRI(Container Runtime)은 다양한 스토리지/네트워크/런타임 솔루션을 지원하기 위해 도입된 표준 인터페이스다.
- Storage Driver들은 CSI 표준에 맞는 rpc들을 정의하고 k8s같은 오케스트레이터가 그 rpc를 호출해 사용한다.
Volume
- k8s의 pod도 container처럼 일시적인 개념이기에 영속성을 위해서 pod에 volume을 연결해야한다.
- hostPath 방법으로 Pod가 올라가있는 노드의 디렉토리를 Volume 저장소로 사용하면 단순해서 편하지만, 멀티 노드 환경에서는 pod가 다른 노드로 이동했을 때 같은 데이터를 갖고 있다는 보장이 없음
- 멀티노드 환경에서는 보통 외부 스토리지를 사용함(NFS, CephFS, 클라우드 스토리지 등등)
Persistent Volume(PV) 와 Persistent Volume Claim(PVC)
- 기존 Volume 방식은 스토리지 변경 사항이 생기면 관련된 모든 pod yaml을 수정해야 해서 비효율적임
- 때문에 스토리지를 중아에서 관리하고 싶을때 PV를 사용함
- PV는 클러스터 전체에서 사용할 수 있는 스토리지 리소스이고, 관리자가 생성함. 사용자는 PVC를 통해 PV를 선택/할당받아 사용함
- PVC와 PV는 1대1관계임. PVC가 요청한 용량이 PV용량보다 더 작아도 상관없지만 남은 용량을 다른 PVC가 쓰는 것은 불가능
- PV가 존재하지 않으면 PVC는 pending 상태로 남는다.
- PVC 삭제시 PV는 Reclaim Policy로 결정됨
- Retail(기본값) : PV는 그대로 남음. 다른 PVC가 재사용할 수도 없음. 수동 삭제 필요
- Delete : PVC 삭제시 PV도 자동 삭제됨
- Recycle(deprecated) : 볼륨 데이터를 지우고 PV를 재사용 가능하게 만드는 방식이지만 실제로는 파일 삭제 수준에 가까워서 deprecated됨
- 현대적인 권장 방식에서는 StorageClass + CSI 기반 Dynamic Provisioning 방식이 표준
Storage Class
Static Provisioning(PV→PVC) 방식
- 만약 gcp persistent disk를 쓴다면 PV를 만들기 전에 gcp에서 디스크를 먼저 수동으로 생성하고 이후에 그 디스크 이름으로 pv yaml을 작성해야 함.
Dynamic Provisioning(StorageClass 이용) 방식
- StorageClass를 이용하여 앱이 스토리지를 필요로 할때 디스크를 자동 생성
- PVC가 생성되는 순간 StorageClass에 설정된 provisioner가 자동으로 스토리지를 만들고 pv도 자동생성. pvc와 자동 바인딩까지 해줌.
- PVC 생성됨
- StorageClass의 provisioner가 필요한 크기의 디스크를 클라우드에 자동 생성
- Kubernetes가 PV를 자동 생성
- PVC ↔ PV 자동 바인딩
- Pod가 PVC를 통해 볼륨 사용
