[Kubernetes Volume] 6. 프로비저닝(Provisioner)의 정의와 스토리지 클래스(StorageClass)

목차

1. 프로비저닝(provisioning)이란?
2. 퍼시스턴트볼륨의 동적 프로비저닝
3. 스토리지클래스 리소스를 통한 스토리지 유형 정의
4. 퍼시스턴트볼륨클레임에서 스토리지 클래스 요청
5. 동적 프로비저닝된 PV와 생성된 PVC 검사하기
6. 다른 클러스터에도 동일하게 적용하기
7. 스토리지 클래스 조회하기
8. 기본 스토리지 클래스 확인하기
9. 스토리지 클래스를 지정하지 않고 PVC 생성하기
10. 퍼시스턴트볼륨클레임을 미리 프로비저닝된 퍼시스턴트볼륨으로 바인딩 강제화하기

---

프로비저닝(provisioning)이란?

쿠버네티스에서 프로비저닝은 일반적으로 저장소와 관련하여 특정 애플리케이션이나 서비스의 요구 사항을 충족시키기 위해 필요한 저장소 자원을 할당하고 구성하는 과정을 의미합니다. 때문에 이번 Volume을 다루는 과정에서 많이 언급되었었죠. 쿠버네티스에서는 두 가지 유형의 프로비저닝이 있습니다. 이번 포스팅에서는 이 2가지 중 동적 포스팅을 위주로 다뤄보겠습니다.

1. 정적 프로비저닝(Static Provisioning)
   정적 프로비저닝에서는 클러스터 관리자가 수동으로 Persistent Volume(PV)을 생성하며, 해당 PV의 용량, 액세스 모드 및 저장소 유형과 같은 하위 저장소의 세부 정보를 지정합니다. 이러한 PV는 사용자가 생성하는 Persistent Volume Claim(PVC)에서 요청될 수 있습니다. 사용자가 PVC를 생성하면 쿠버네티스는 해당 PVC의 요구 사항과 일치하는 사용 가능한 PV에 바인딩합니다.
   
   
2. 동적 프로비저닝(Dynamic Provisioning)
   동적 프로비저닝에서는 PVC 요청에 대한 PV를 자동으로 생성하는 과정을 자동화합니다. 클러스터 관리자는 PV 생성을 위한 템플릿인 StorageClass를 정의합니다. 각 StorageClass는 PV를 생성하는 책임이 있는 프로비저너(Provisioner)를 지정합니다. 사용자가 특정 StorageClass를 참조하는 PVC를 생성하면 프로비저너는 PVC의 요구 사항과 일치하는 PV를 자동으로 생성하여 클러스터 관리자의 수동 개입을 없애줍니다.

---

퍼시스턴트볼륨의 동적 프로비저닝

이전 포스팅에서 퍼시스턴트볼륨(PV)과 퍼시스턴트볼륨클레임(PVC)을 사용함으로써 개발자가 내부적으로 사용된 실제 스토리지 기술을 처리할 필요 없이 얼마나 쉽게 퍼시스턴트 스토리지를 사용 할 수 있는지 살펴봤습니다. 그러나 클러스터 관리자는 실제 스토리지를 미리 프로비저 닝해둬야 합니다. 다행히 쿠버네티스는 퍼시스턴트볼륨의 동적 프로비저닝을 통해 이 작업을 자동으로 수행할 수 있습니다.

 

클러스터 관리자가 퍼시스턴트볼륨을 생성하는 대신 퍼시스턴트볼륨 프로비저너를 배포하고 사용자가 선택 가능한 퍼시스턴트볼륨의 타입을 하나 이상의 스토리지클래스 Storage Class 오브젝트로 정의할 수 있습니다. 사용자가 퍼시스턴트볼륨클레임에서 스토리지 클래스를 참조하면 프로비저너(provisioner)가 퍼시스턴트 스토리지를 프로비저닝할 때 이를 처리합니다. 퍼시스턴트볼륨과 비슷하게 스토리지클래스 리소스도 네임스페이스에 속하지 않습니다.

 

쿠버네티스는 대부분 인기 있는 클라우드 공급자의 프로비저너를 포함하므로 관리자가 항상 프로비저너를 배포하지 않아도 된다는 장점이 있습니다. 그러나 온-프레미스에 배포된 쿠버네티스는 사용자 정의 프로비저너가 배포돼야 합니다.

 

관리자가 많은 퍼시스턴트볼륨을 미리 프로비저닝하는 대신 하나 혹은 그 이상의 스토 리지클래스를 정의하면 시스템은 누군가 퍼시스턴트볼륨클레임을 통해 요청 시 새로운 퍼시스턴트볼륨을 생성합니다. 가장 큰 장점은 퍼시스턴트볼륨이 부족할 일이 없다는 것입니다. 물론, 스토리지 용량은 부족할 수 있습니다.

---

스토리지클래스 리소스를 통한 스토리지 유형 정의

사용자가 퍼시스턴트볼륨클레임을 생성하면 결과적으로 새로운 퍼시스턴트볼륨이 프로비저닝되므로 관리자는 하나 혹은 그 이상의 스토리지클래스 리소스를 생성해야 합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd       >  퍼시스턴트볼륨 프로비저닝을 위해사용되는 볼륨 플러그인입니다.
parameters:
  type: pd-ssd                                       >  이런 파라미터가프로비저너로 전달됩니다.
  zone: europe-west1-b

스토리지클래스 리소스는 퍼시스턴트볼륨클레임이 스토리지클래스에 요청할 때 어떤 프로비저너가 퍼시스턴트볼륨을 프로비저닝하는 데 사용돼야 할지를 지정합니다. 스토리지 클래스에 정의된 파라미터들은 프로비저너에 전달되며, 파라미터는 각 프로비저너 플러그인마다 다릅니다.

 

이 스토리지클래스는 구글 클라우드 엔진GCE의 퍼시스턴트 디스크 프로비저너를 사용하므로 GCE에서 쿠버네티스가 실행 중일 때 사용할 수 있습니다는 뜻입니다. 다른 클라우드 공급자인 경우 다른 프로비저너를 사용해야 합니다.

---

퍼시스턴트볼륨클레임에서 스토리지 클래스 요청

스토리지클래스 리소스가 생성되면 사용자는 퍼시스턴트볼륨클레임의 이름에 스토리지클래스를 참조할 수 있습니다. 다음 매니페스트로 특정 스토리지클래스를 요청하는 PVC 정의 생성할 수 있습니다. Mongodb-pvc를 동적 프로비저닝을 사용하도록 정의했습니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: mongodb-pvc
spec:
    storageClassName: fast            >  PVC는 사용자 정의 스토리지클래스를 요청합니다.
    resources:
        requests:
            storage: 100Mi
        accessModes:
        - ReadWriteOnce

크기와 접근 모드를 지정하는 것 외에도 퍼시스턴트볼륨클레임에 사용할 스토리지클래스를 지정해야 합니다. 클레임을 생성하면 fast 스토리지클래스 리소스에 참조된 프로비저너가 퍼시스턴트볼륨을 생성합니다. 프로비저너는 수동으로 프로비저닝된 퍼시스턴트볼 륨과 퍼시스턴트볼륨클레임을 매핑하는 데도 사용됩니다.

---

동적 프로비저닝된 PV와 생성된 PVC 검사하기

위 방법으로 PVC를 생성하고 kubectl get을 사용해 확인합니다.

 

$ kubectl get pvc mongodb-pvc NAME

 

VOLUME 열은 클레임에 바인딩된 퍼시스턴트볼륨을 표시합니다. 이 때 표시되는 이름보다 실제 이름이 훨씬 깁니다. 다음으로 퍼시스턴트볼륨을 조회해서 실제로 PV가 자동으로 생성됐는지 확인해보겠습니다.

 

$ kubectl get pv

 

동적으로 프로비저닝된 퍼시스턴트볼륨을 볼 수 있습니다. 퍼시스턴트볼륨의 용량과 접근 모드가 PVC에서 요청한 것과 동일할 것입니다. 리클레임 정책(RECLAIMPOLICY 열)은 Delete로 PVC가 삭제되면 퍼시 스턴트볼륨이 삭제됨을 의미합니다. PV 외에 프로비저너는 실제 스토리지도 프로비저닝했습니다. fast 스토리지클래스는 GCE 퍼시스턴트 디스크를 프로비저닝하는 kubernetes.io/gce-pd 프로비저너를 사용하도록 설정됐습니다. 다음 명령으로 디스크를 확인합니다.

 

$ gcloud compute disks list

 

퍼시스턴트 디스크의 이름에 gke-kubia-dyn-pvc-...으로 출력됐을 것이고, 동적으로 프로비저닝됐음을 나타냅니다.

---

다른 클러스터에도 동일하게 적용하기

클러스터 관리자는 성능이나 기타 특성이 다른 여러 스토리지 클래스를 생성할 수 있습니다. 그런 다음 개발자는 생성할 각 클레임에 가장 적합한 스토리지 클래스를 결정합니다.

 

스토리지클래스의 좋은 점은 클레임 이름으로 이를 참조합니다는 사실입니다. 그러므로 다른 클러스터 간 스토리지클래스 이름을 동일하게 사용한다면 PVC 정의를 다른 클러스터로 이식 가능합니다.

 

PVC 정의를 다른 클러스터로 이동해야 할 경우, 동일한 YAML 파일을 대상 클러스터에 적용하기만 하면 됩니다.

kubectl apply -f pvc-yaml-name.yaml

이와 같이 각 클러스터에서 동일한 StorageClass 이름을 사용하면 클러스터마다 YAML 파일을 수정할 필요 없이 PVC 정의를 쉽게 이식할 수 있습니다. 단, 이 프로세스는 PV에 저장된 실제 데이터를 이동시키지는 않으므로, 스토리지 솔루션 및 요구 사항에 따라 데이터 복제 또는 백업 및 복원과 같은 다른 접근 방식을 사용해야 합니다.

---

스토리지 클래스 조회하기

fast라는 사용자 정의 스토리지 클래스를 생성할 때 클러스터에 스토리지 클래스가 이미 정의돼 있는지 확인하지 않았다. 지금 확인해봅시다. GKE에서 사용 가능한 스토리지 클래 스는 다음과 같습니다.  storageclass의 약어로 SC를 사용할 수 있습니다.

 

$ kubectl get sc

출력 내용

NAME                         TYPE
fast                              kubernetes.io/gce-pd
standard(default)         kubernetes.io/gce-pd

직접 생성한 fast 스토리지 클래스 외에 standard 스토리지 클래스가 기본값(default) o 로 표시돼 있습니다. 이것이 무슨 의미인지 Minikube에서 사용 가능한 스토리지 클래스를 조회해서 비교해보겠습니다.

 

$ kubectl get sc

출력 내용

NAME                         TYPE
fast                              k8s.io/minikube-hostpath
standard(default)         k8s.io/minikube-hostpath

여기에도 생성한 fast 스토리지 클래스가 있고 기본값으로 standard 스토리지 클래스 가 존재합니다. 두 조회 결과에서 TYPE 열을 비교해보면 GKE는 kubernetes.io/gce-pd 프로비저너를 사용하고 Minikube는 k8s.io/Minikube-hostpath를 사용합니다.

---

기본 스토리지 클래스 확인하기

다음과 같이 kubectl get을 사용해 GKE 클러스터의 standard 스토리지 클래스를 자세히 살펴보겠습니다. 이 때 끝에 " > (파일이름).yaml "을 입력하면 해당 내용의 yaml 파일을 생성할 수도 있습니다.

$ kubectl get sc standard -o yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.beta.kubernetes.io/is-default-class: "true"  >  이 어노테이션에서 스토리지 클래스를 기본값으로 
  creationTimestamp: 2017-05-16T15:24:117                          표시합니다.
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: standard
  resourceVersion: "180"
  selfLink:/apis/storage.k8s.io/v1/storageclassesstandard
  uid: b6498511-3a4b-11e7-ba2c-42010a840014
parameters:                                                       >    type 파라미터는 프로비저너가 어떤 유형의 GCE PD를 
  type: pd-standard                                                  생성할지 알려줍니다.
provisioner: kubernetes.io/gce-pd GCE            >  퍼시스턴트 디스크 프로비저너는 이 클래스의 PV 프로비저닝
                                                                              하는 데 사용합니다.

예제의 맨 위를 자세히 살펴보면 스토리지 클래스 정의에 어노테이션이 포함돼 있으므로 이 스토리지 클래스가 기본값이 됩니다. 기본 스토리지 클래스는 퍼시스턴트볼륨클레임 에서 명시적으로 어떤 스토리지 클래스를 사용할지 지정하지 않은 경우 퍼시스턴트볼륨을 동적 프로비저닝하는 데 사용됩니다.

---

스토리지 클래스를 지정하지 않고 PVC 생성하기

storageClassName 속성을 지정하지 않고 PVC를 생성하면 구글 쿠버네티스 엔진에서는 pd-standard 유형의 GCE 퍼시스턴트 디스크가 프로비저닝됩니다. 다음 YAML로 클레임을 생성할 수 있습니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pvc2
spec:                                             >  이전 예제와 다르게 storageClassName 속성을 지정하지 않았습니다.
  resources:
    requests:
      storage: 100mi
  accessModes:
  - ReadWriteOnce

 

이 PVC 정의는 단지 스토리지 사이즈와 의도된 접근 모드만을 지정하고 스토리지 클 래스를 포함하지 않는다. PVC를 생성하면 기본값으로 표시된 스토리지 클래스가 사용됩니다. 다음과 같이 확인할 수 있습니다.

 

$ kubectl get pvc mongodb-pvc2

$ kubectl get pv pvc-95a5ec12(이 문자 배열은 달라질 수 있습니다.)

$ gcloud compute disks list

---

퍼시스턴트볼륨클레임을 미리 프로비저닝된 퍼시스턴트볼륨으로 바인딩 강제화하기

PVC 정의에서 관련 있는 행을 다시 살펴 보겠습니다.

kind: PersistentVolumeClaim
spec:
  storageClassName:  ""           >  빈 문자열을 스토리지클래스 이름으로 지정하면 PVC가 새로운 PV를 동적
                                                     프로비저닝하는 대신 미리 프로비저닝된 PV에 바인딩됩니다.

storageClassName 속성을 빈 문자열로 지정하지 않으면 미리 프로비저닝된 퍼시스턴 트볼륨이 있다고 할지라도 동적 볼륨 프로비저너는 새로운 퍼시스턴트볼륨을 프로비저닝할 것입니다.

 

PVC를 미리 프로비저닝된 퍼시스턴트볼륨에 바인딩하려면 명시적으로 storageClassName 을 ""(큰따옴표)로 지정해야 합니다. 요약하면 파드에 퍼시스턴트 스토리지를 연결하는 최적의 방법은 (storageClassName을 명시적으로 지정한) PVC와 (PVC를 이름으로 참조한) 파드만 생성하는 것입니다. 이외의 다른 모든 것은 동적 퍼시스턴트볼륨 프로비저너가 처리합니다.