[CKA] 컨테이너 저장소

Docker Volume (가장 기본적인 컨테이너 저장소)

pod는 기본적으로 두가지 Layer기반으로 운영된다. 컨테이너 레이어(읽기 + 쓰기 가능)과 이미지 레이어(읽기 가능) 읽기만 가능한 이미지 레이어의 경우 이미 docker를 통해 이미지화가 되어 있기에 수정이 불가능하다. (이미지 파일의 소스코드는 수정할 수 없음)

기본적으로 컨테이너 레이어는 휘발성이다. 그렇기에 volume이라는 Docker에서 제공하는 별도의 저장소를 활용할 수 있다.

이런 Volume을 기반으로 컨테이너 환경에서 저장소는 더욱 발전되어진다.

Docker Volume → emptyDir, hostPath, persistentVolumeClaim…

---

PersistentVolume

기존의 Volume은 pod가 재시작되지 않고 아예 삭제되면 저장소가 날라간다. 이러한 기능을 극복하기 위해 PersistentVolume라는 개념이 나왔다.

더이상 삭제될 수 있는 emptyDit를 사용하지 않고 PersistentVolume를 사용하자!

PersistentVolume yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /pv/log

PersistentVolumeClaim

PV를 만들었으면 어떤식으로 매핑 해야할까? 이전에 만든 yaml을 기반으로 pod가 해당 PV를 사용하기 위해 요청서가 필요하다.

Pod: 🙋 저는 스토리지 1G와 읽고쓰기 정책이 필요한 PV가 필요해요!

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

이렇게 하면 쿠버네티스는 조건에 맞는 PV를 자동으로 바인딩 시킨다.

이를 통해 개발자는 직접 PV를 만들지 않고 PVC를 통해 PV를 자동으로 할당 받으며 동적으로 저장소를 관리할 수 있게 된다.

PV를 사용하는 Pod yaml

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: event-simulator
    image: kodekloud/event-simulator
    env:
    - name: LOG_HANDLERS
      value: file
    volumeMounts:
    - mountPath: /log
      name: log-volume

  volumes:
  - name: log-volume
    persistentVolumeClaim:
      claimName: claim-log-1

webapp은 PVC를 참조하고 해당 PVC가 어떤 PV와 연결이 되어있는지는 관심이 없다.

즉 간접적으로 PV는 모른채 PV를 이용할 수 있는 패턴이 완성된다.

외부 저장소 활용 (Container Storage Driver)

기존 Azure Key Vault에서 활용한 CSI처럼 쿠버네티스는 외부 저장소를 사용이 가능한데, 각 외부 저장소와 컨테이너의 표준을 맞추기 위해 사용되는 인터페이스가 CSI이다.

즉 컨테이너 → CSI 드라이버 → 외부 Storage의 흐름으로 이어진다.

CSI를 사용하는 저장소

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: csi-hostpath-sc
  resources:
    requests:
      storage: 1Gi