쿠버네티스 볼륨 알아보기

쿠버네티스에서 pod는 특정 이미지를 사용하여 컨테이너를 자유롭게 생성하고 지웠다를 반복할 수 있다.

문제는 pod가 삭제되고 재생성될 때 이미지에 포함되지 않은 추가적으로 생성된 파일이나 폴더 같은 데이터들은 모두 삭제된다는 것이다.

 

예를 들어 mysql 이미지를 사용하여 pod를 생성했다고 가정하자. 그리고 hokka라는 계정을 추가하고 이름이userdata인 데이터베이스를 생성한 상태에서 pod를 삭제 후 재생성한다. 그러면 새로 올라온 pod에서 mysql이 동작하는 것은 동일하지만 이전에 생성했던 hokka라는 계정과 userdata 라는 데이터베이스는 모두 삭제되어 없어지게 된다.

 

이러한 문제점을 해결하기 위해 쿠버네티스에서는 pv와 pvc, sc라는 리소스를 통해 pod가 영구적인 데이터를 가지고 사용할 수  있도록 지원하고 있다.

 

쿠버네티스 볼륨 아키텍처

---

pod에서 영구 볼륨을 사용하기 위해 필요한 단계

먼저 간략하게 볼륨을 구성하는 리소스들을 설명하자면 pv는 실제 생성되는 볼륨, pvc는 pv를 요청하기 위한 명세서, sc는 pv의 볼륨 설정 정책 등을 그룹화해둔 리소스이다. 

위 사진을 보면 pod는 pvc를 통해 원하는 볼륨 구성을 요청하고,  pv controller가 pvc에 조건에 부합하는 pv를 생성하여 pod에 마운트해준다.

만약 pv를 동적으로 생성하는 상황이라면 스토리지 클래스의 설정들을 상속받아 nfs와 연결하거나 AWS, GCP와 같은 클라우드 플랫폼의 볼륨 서비스와 연계하여 사용할 수도 있다.

 

프로비저닝 방식

---

볼륨과 관련된 리소스들을 자세하게 설명하기 전에 볼륨들이 어떠한 방식으로 프로비저닝 되는지에 대해 알아야 한다.

쿠버네티스에서는 크게 정적 프로비저닝과 동적 프로비저닝 2가지 방식을 지원한다.

 

먼저 정적 프로비저닝에 대해 알아보자.

정적 프로비저닝 프로세스

정적 프로비저닝은 pod에서 사용할 pv를 사전에 수동으로 생성해 두고 이를 pod에 매칭시키는 방식이다.

주로 한정적인 용량을 사용하는 온프레미스 환경이나 권한이나 정책 등 체계가 잡혀있는 곳에서 많이 사용한다.

장점으로는 pod가 요청하는 볼륨을 사전에 미리 만들어둬야 하기 때문에 자원에 대한 현황 파악을 명확하게 할 수 있다.

 

두 번째로는 동적 프로비저닝이다.

동적 프로비저닝 프로세스

동적 프로비저닝은 pod가 pvc를 통해 볼륨을 요청하면 해당 요구사항에 맞추어 pv를 자동으로 생성하여 pod에 제공하는 방식이다.

주로 사용할 수 있는 용량에 제한이 걸려있지 않은 클라우드 환경 혹은 신속한 스케일링을 요구하는 개발 환경 등에서 많이 사용한다.

장점으로는 볼륨에 대한 요청이 들어올 때 실제로 리소스가 생성되기 때문에 안 쓰거나 버리는 자원 없이 효율적으로 관리할 수 있다. 또한 직접 pv를 생성하지 않아도 되기 때문에 정적 프로비저닝처럼 관리자가 번거롭게 작업하지 않아도 된다.

 

이제 아키텍처와 프로비저닝 방식에 대해 알았으니 실제 볼륨들을 구성하는 리소스들에 대해서 알아보자.

 

StorageClass(SC)

---

스토리지 클래스는 주로 동적 프로비저닝 방식을 사용할 때 참조되는 리소스이며 네임스페이스의 영향을 받지 않는다.

동적 볼륨을 생성하는 방식에는 위에서 설명한 csp 서비스와의 연계, nfs, local 등 여러 가지가 있다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: low-latency
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-driver.example-vendor.example
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - discard
volumeBindingMode: WaitForFirstConsumer
parameters:
  guaranteedReadWriteLatency: "true"

옵션을 보면 pv의 수명주기 정책을 설정하는 reclaimPolicy부터 마운트 설정을 지정하는 mountOptions, 기타 파라미터들을 설정할 수 있다.

또한 csp 환경에서 클러스터를 운영하고 있다면 provisioner를 각 클라우드 플랫폼별로 맞게 지정하여  AWS의 경우 ebs, efs 등과 연계하여 사용할 수 있다.(물론, 각 플랫폼에 맞는 스토리지 클래스 리소스들을 설치해야 사용 가능하다)

 

이렇게 볼륨에 대한 여러 가지 설정들을 스토리지 클래스로 그룹화해 두었다면 이후에 pvc를 생성할 때 스토리지 클래스의 이름을 지정해 주는 것으로 해당 설정들을 새로 만들 볼륨들이 가져다 쓸 수 있게 되는 것이다.(단, 동적 프로비저닝일 때 가능)

 

아래는 스토리지 클래스에서 지원하는 provisioner 종류이다.

 

Persistent Volume Claim(PVC)

---

pvc는 pod가 사용할 pv를 요청 혹은 생성하기 위해 필요한 내용들을 담아둔 리소스이며 네임스페이스의 영향을 받는다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
  storageClassName: manual

yaml 내용을 보면 pvc의 이름을 포함하여 볼륨을 어떤 방식(mode)으로 사용할 건지에 대한 명시가 담겨있다.

위 예시에서는 ReadWriteOnce라는 모드를 사용했는데 이는 하나의 노드에서만 볼륨을 마운트 해서 사용할 수 있도록 설정하는 것을 의미한다.

 

이외에도 여러 노드에서 동일한 pv를 사용할 수 있도록 하는 ReadWriteMany 등 다양한 모드가 존재한다.

k8s 에서 공식적으로 지원하는 볼륨 모드 종류

또한 용량을 얼마나 할당할 건지에 대해서 설정되어 있고, 어떤 스토리지 클래스(예시에서는 manual)를 사용할 건지 명시해 두었기 때문에 동적 프로비저닝을 사용하는 것을 알 수 있다.

 

여기서 만약 정적 프로비저닝을 이용하고 싶다면 storageClassName값을 명시해 줄 때 ""로 입력하고 VolumeName 옵션을 추가하여 바인딩할 pv의 이름을 값으로 적어주면 된다.

예를 들어 test-pv라는 정적 볼륨에 바인딩하기 위한 pvc의 내용은 아래와 같다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  volumeName: test-pv
  resources:
    requests:
      storage: 10Gi
  storageClassName: ""

만약 위와 같이 pvc를 생성했는데 test-pv라는 pv가 만들어져있지 않다면 pvc는 pending 상태로 머무르게 된다.

 

Persistent Volume(PV)

---

실제 생성되는 볼륨 리소스로, pvc에서 명시한 내용들을 포함하여 생성된 볼륨의 상태 정보들을 가지고 있으며 네임스페이스의 영향을 받지 않는다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  storageClassName: manual
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /home/test-pv

위 예시는 hostpath 방식을 이용해 생성한 pv로 노드의 /home/test-pv 경로를 pod의 볼륨으로 사용할 수 있게끔 설정되어 있다.

추가로 persistentVolumeReclaimPolicy라는 옵션이 있는 걸 볼 수 있는데 이는 pv가 삭제되었을 때 남아있는 데이터를 어떻게 처리할지에 대해 설정하는 옵션이다.

예시에서는 delete로 되어있기 때문에 pv가 삭제되면 해당 pv안에 있던 실제 데이터들은 모두 삭제된다.

 

delete 이외에도 retain(pv가 삭제되어도 안에 데이터는 보존), recycle(데이터들을 모두 삭제하고 pv를 재사용할 수 있도록 초기화) 옵션이 지원되며 각 상황에 알맞은 옵션으로 사용하면 된다.

k8s 공식 문서에서는 recycle 정책에 대해 더 이상 사용하지 않는다고 명시되어 있으며 기존 볼륨을 재활용하기보다는 동적 프로비저닝 방식을 통해 새 볼륨을 생성해서 사용하는 것을 권장하고 있다.

 

아래는 persistent volume에서 사용할 수 있는 플러그인 유형들이다.

다양한 유형을 지원했던 과거에 비해 현재는 범용성이 좋은 타입의 플러그인들에 집중해서 지원하고 있다.

 

참고자료

---

Storage Classes

퍼시스턴트 볼륨