Kubernetes - Persistent storage

- 출처: Kubernetes in action

- 퍼시스턴트 스토리지

파드에서 실행중인 앱이 Disk에 데이터를 유지해야 하거나 파드가 다른 노드로 재 스케줄링 된 경우에도 동일한 데이터를 사용해야 한다면 NAS(network-attached-storage) 유형에 저장돼야 한다.

 

MongoDB를 Persistent disk에 연동하는 예제를 살펴보자. minikube 환경이기 때문에 hostPath로 흉내내본다.

 

apiVersion: v1
kind: Pod
metadata:
  name: mongodb
spec:
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db
    ports:
    - containerPort: 27017
      protocol: TCP
  volumes:
  - name: mongodb-data
    hostPath:
      path: /Users/user/Documents/Study/kubernetes/chapter06
      type: DirectoryOrCreate

 

volumes 에는 hostPath 형의 mongodb-data 볼륨을 정의한다. 그리고 이를 container의 /data/db 경로에 마운트한다.

 

"kubectl exec -it -- mongosh" 명령어로 mongosh을 실행시켜보자. 

 

 

 

몇 가지 데이터를 넣어준다. mystore DB에 foo collection으로 데이터를 넣어주고 잘 삽입되었는지 확인해준다.

 

 

 

이제 mongo pod을 종료한 뒤에도 데이터가 유지되었는지 확인해주자. pod 삭제 > 재생성 > mongosh 수행 > find query를 수행해서 이전에 insert 한 데이터가 남아있는지 확인해준다.

 

---

- 기반 스토리지 기술과 파드 분리

여태까지 살펴본 예제는 파드 개발자가 실제 스토리지 인프라스트럭쳐 관련 지식을 갖춘 상태라는것을 전제로 한다. 하지만 이는 쿠버네티스의 기본 사상인 인프라스트럭쳐의 세부사항을 앱과 개발자로부터 숨긴다는 사상에 맞지 않는다.

 

인프라스트럭쳐 세부사항을 처리하지 않고 애플리케이션이 쿠버네티스 클러스터에 스토리지를 요청할 수 있도록 하기 위한 새로운 리소스인 퍼시스턴트 볼륨(PV)와 퍼시스턴트 볼륨 클레임(PVC)를 소개한다.

 

• 클러스터 관리자: 네트워크 스토리지 유형을 설정한다. 쿠버네티스 API에 PV 디스크립터를 게시하여 PV를 생성(PV 프로비저닝)한다.
• 사용자(파드 개발자): PVC를 생성한다. 쿠버네티스는 적절한 크기와 접근 모드를 가진 PV를 찾고 PVC를 PV에 바인딩한다. 사용자는 PVC를 참조하는 볼륨을 가진 파드를 생성한다.

 

PV를 한번 생성해보자. minikube 환경이므로 hostPath 형의 mongodb-pv 를 생성한다.

 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongodb-pv
spec:    storageClassName: ""
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /Users/user/Documents/Study/kubernetes/chapter06
    type: DirectoryOrCreate

 

PV 생성시 관리자는 쿠버네티스에게 용량이 얼마나 되는지를 알려주어야 한다. 이를 capacity에 기술한다. 또 accessModes 항목에는 단일 클라이언트의 읽기/쓰기 용, 여러 클라이언트를 위한 읽기 전용으로 마운트됨을 기술하고 있다.

 

PV는 특정 네임스페이스에 속하지 않으며 노드와 같은 클러스터 수준의 리소스이다.

 

이제 개발자의 입장을 살펴보자.

 

위에서 생성한 PV는 파드에서 직접 사용은 불가하며 PVC를 생성해야 한다. 파드가 재 스케줄링 되어도 동일 PVC가 사용가능 상태로 유지되어야 하기 때문에 PVC는 파드 생성과 별개의 프로세스이다.

 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc
spec:
  storageClassName: ""
  resources:
    requests:
      storage: 1Gi
  accessModes:
  - ReadWriteOnce
  volumeName: mongodb-pv

 

PVC가 생성되면 쿠버네티스는 PV를 바인딩한다. PV와 PVC를 조회해보면 아래와 같이 잘 바인딩됨을 확인할 수 있다

 

 

 

PVC 조회시 접근 모드를 약어로 표기하는데 의미는 다음과 같다.

 

• RWO(Read Write Once): 단일 노드만 읽기 / 쓰기 용으로 볼륨 마운트
• ROX(Read Only Many): 다수 노드가 읽기 용으로 볼륨 마운트
• RWX(Read Write Many): 다수 노드가 읽기 / 쓰기 용으로 볼륨 마운트

---

- 파드에서 PVC 사용

 

PV가 사용중이면 볼륨 해제까지 다른 사용자는 동일 볼륨에 클레임할 수 없다. 파드 볼륨에서 PVC를 참조해보자.

 

apiVersion: v1
kind: Pod
metadata:
  name: mongodb
spec:
  containers:
  - image: mongo
    name: mongodb
    volumeMounts:
    - name: mongodb-data
      mountPath: /data/db
    ports:
    - containerPort: 27017
      protocol: TCP
  volumes:
  - name: mongodb-data
    persistentVolumeClaim:
      claimName: mongodb-pvc

 

앞의 mongodb hostPath 유형 볼륨 참조 파드 yaml 파일을 mongodb-pvc 참조로 변경하자.

 

 

 

PV와 PVC를 생성하면 이 두 리소스를 추가하는 절차가 추가되긴 하지만 개발자는 스토리지에 대한 세부사항을 알 필요가 없다.;