8. Storage

- 도커 스토리지 드라이버

 

도커 이미지는 레이어 구조

레이어를 공유해서 저장공간, 속도 장점

도커 이미지 레이어는 read only로 레이어의 파일을 수정하는 경우 컨테이너 레이어에서 CoW(Copy on Write, 원본을 그대로 두고 복사본을 생성해서 해당 복사본을 수정) 모드로 동작하지만 컨테이너가 삭제되는 경우 데이터가 소멸됨

 

스토리지 드라이버는 overlay, zfs, device mapper 등(OS마다 디폴트가 다름)으로 이러한 도커의 레이어 스토리지 구조를 담당

 

 

- 볼륨 드라이버

수정사항을 유지하고 싶은 경우 볼륨 생성, 마운트

 

-- 볼륨 경로를 지정하는 경우 (bind mount)

로컬의 특정 경로를 마운트

 

-- 볼륨 경로를 지정하지 않고 이름을 주는 등 (volume mount)

도커의 볼륨 기능을 사용 (docker volume create로 수동 생성하거나, 자동 생성됨)

/var/lib/docker/volumes 경로에 저장됨

 

기본은 로컬이고, 클라우드에서 제공하는 다양한 볼륨 드라이버를 명시해서 사용 가능

 

-- CSI(Container Storage Interface): amazon ebs, azure 등 스토리지용 인터페이스 (쿠버네티스용만은 아님)

-- CRI(Runtime): 도커(현재 x), containerd 등 여러 컨테이너 런타임의 종류와 관계없이 오케스트레이션을 하기위한 인터페이스

-- CNI(Network): 마찬가지로 flannel, weave 등 네트워크

 

 

- 볼륨

컨테이너의 데이터는 휘발성이므로 볼륨을 만들어 남김

볼륨을 위한 스토리지는 다양할 수 있음 (노드에 저장 등)

노드가 여러개일 경우 데이터가 중복되고 일치하지 않을 수 있음

따라서 분산형 스토리지로 nfs, cephfs 등 또는 클라우드 기반 스토리지 사용

 

 

- PV(Persistent Volume)

일반 볼륨은 pod에 종속적임

여러 pod이 자원 형태로 볼륨을 사용하기 위해 PV 사용

큰 덩어리 형태로 볼륨을 구성하고, 이를 분할해서 각 앱에서 사용 (PVC)

ro, rw(1회/다회)

 

PVC가 삭제된 경우의 정책

-- retain: 파일이 유지되고 사용할 수 없는 상태(Released)가 됨

-- delete: 파일 삭제 후 소멸 (클라우드 등에서 사용)

-- recycle: 파일 삭제 후 다시 사용 가능한 상태가 됨

 

- PVC(PV Claim)

PVC로 볼륨을 요청하는 경우 쿠버네티스가 조건(mode, 용량 등) 확인 후 PV에 해당 요청을 바인딩해줌 (논리 구조)

특정 PV를 사용하고 싶은 경우 label, selector 사용

PV와 PVC는 1대1 대응이므로 PV에 공간이 남았더라도 다른 pod에서 해당 PV를 사용할 수 없음 (pending)

즉, request 용량보다 크더라도 전체 용량을 할당받음

PVC가 사용 중 삭제된 경우 pod에서 붙잡고있기 때문에 terminating 상태에서 멈춰있음

 

 

- 스토리지 클래스

 

-- static provisioning: 직접 클라우드에서 디스크 생성하고 해당 이름으로 PV 생성

-- dynamic provisioning: yaml 파일 기반으로 자동으로 클라우드에 스토리지 생성

SC를 생성하면 클라우드에 저장공간이 형성되고 자동으로 이에 맞는 PV가 생성

즉 SC는 로컬, 클라우드에 관계없이 PV를 생성하고 그룹핑 하기위한 인터페이스라고 생각하면 될듯

 

SC의 볼륨 바인딩 모드

-- WaitForFirstConsumer: 사용할 pod이 나타나기 전까지 PVC가 PV를 잡지 않음

-- Immediate: 즉시 잡음