들어가며
- kubernetes의 볼륨은 다양하게 존재하고 있습니다.
- 우리가 볼륨으로 사용할 수 있는 storage는 제한적입니다.
- 그렇다면, 제한적인 storage를 사용하고 제공하는 방법은 정해야 합니다.
- 이때 kubernetes가 제공하는 API인 pv와 pvc를 사용할 수 있습니다.
PV, PVC란?
pv(persistent volume)는 관리자에 의해 생성된 볼륨입니다. cluster의 resource이며, pod와는 별개의 life cycle을 가지고 있습니다.
pvc(persistent volume claim)은 사용자가 storage를 사용하기 위해 pv에게 하는 요청입니다. pod는 node의 resource를 사용하고, pvc는 pv의 resource를 사용하게 됩니다.
PV는 cluster resource입니다. PVC는 해당 resource에 대한 요청이며, resource에 대한 claim 검사 역할을 합니다.
PV와 PVC 간의 상호 작용은 다음 life cycle을 따릅니다.
pv/pvc life cycle
Provisioning
pv를 만드는 단계가 provisioning입니다.
provisioning 방법에는 2가지가 있습니다.
pv를 미리 만들어 두고 사용하는 정적 방법과, 요청이 들어올 때 마다 만드는 동적 방법 입니다.
- Static Provisioning (정적 프로비저닝)
cluster 관리자는 적당한 사이즈의 pv를 미리 만들어 두고, 사용자의 요청이 들어오면 만들어둔 pv를 할당하게 됩니다. - Dynamic Provisioning (동적 프로비저닝)
관리자가 생성한 정적 pv가 사용자의 pvc와 일치하지 않으면 cluster는 pvc를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있습니다.
pvc는 동적 프로비저닝할 때 여러가지 스토리지 중 원하는 스토리지를 정의하는 스토리지 클래스(Storage Class)로 pv를 생성합니다.
Binding
바인딩(Binding)은 프로비저닝으로 만든 pv를 pvc와 연결하는 단계입니다.
일치하는 볼륨이 없는 경우 claim은 무한정 바인딩되지 않은 상태로 남아 있습니다.
일치하는 볼륨이 제공되면 claim이 바인딩됩니다.
Using
pod는 pvc를 볼륨으로 사용합니다.
cluster는 pvc을 검사하여 바인딩된 볼륨을 찾고 해당 볼륨을 pod에 마운트합니다.
Reclaiming
사용자가 볼륨을 다 사용하면, pvc는 삭제할 수 있습니다.
pvc를 삭제하면 pvc를 사용하던 pv를 초기화(reclaim)하는 과정을 거칩니다.
이를 Reclaiming(반환)이라고 합니다.
SparklingSoDA에서 사용하는 PV, PVC
SparklingSoDA 4.0 기준으로 pv와 pvc를 조회해 보겠습니다.
kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-pvc Bound pvc-674793e8-aae6-47f0-b3d4-b84eecd3d24c 10Gi RWO nas-client 43d data-volume Bound pvc-b87ad0f2-c2f5-4281-8415-82b6d4fdbfbc 10Gi RWO nas-client 43d docker-cache-volume Bound pvc-151a2e34-2323-4281-8379-c3c1dfd0990d 10Gi RWO nas-client 43d docker-volume Bound pvc-94ac04dc-1ac7-4e79-ac7a-fc8af5bf3abd 10Gi RWO nas-client 43d gitlab-postgresql Bound pvc-8ed443e9-1bbc-4675-aeb3-6c243e4e5315 10Gi RWO nas-client 43d gitlab-redis Bound pvc-557a1c09-2797-4ba7-851f-4adaaebb9f5d 5Gi RWO nas-client 43d gitlab-server Bound pvc-5ec182d1-c25d-4a72-834c-a006ad6d934c 5Gi RWO nas-client 43d mariadb-primary-volume Bound pvc-eb72244f-86aa-4ba2-aff7-f3b2b2d5bf78 8Gi RWO nas-client 43d mariadb-secondary-volume Bound pvc-af84f80a-e5db-41be-bd20-5bdd17b998e5 8Gi RWO nas-client 43d nexus-data-volume Bound pvc-20c22e74-834b-4842-b159-ca06a72cd793 200Gi RWX nas-client 44d polyaxon-artifacts-store Bound pvc-0548619f-5e77-4b13-a99c-c05961a9e4cf 100Gi RWX nas-client 43d polyaxon-postgresql-data Bound pvc-39438b64-9c12-4062-9e2d-1eb804e1be3b 10Gi RWX nas-client 43d pvc-nfs-client-nfs-client-provisioner Bound pv-nfs-client-nfs-client-provisioner 10Mi RWO 44d restapp-volume Bound pvc-931a33a3-ae2a-4a8c-9b84-fddb84d677c0 10Gi RWO nas-client 43d
STATUS 값이 binding인 것을 확인할 수 있습니다. pv와 pvc가 연결되어, 사용할 수 있는 상태입니다.
한가지 예시로, nexus의 pvc를 생성하는 방법과, pod에서 pvc를 사용하는 방법을 보겠습니다.
pvc생성하는 yaml 파일
apiVersion: v1 metadata: name: nexus-data-volume namespace: sodaflow labels: app.kubernetes.io/component: "nexus" spec: storageClassName: nas-client accessModes: - ReadWriteMany resources: requests: storage: 200Gi
위 yaml은, nexus-data-volume 이라는 pvc를 생성합니다.
사용할 storage class는 nas-client이고, 접근 권한은 RW many(다수의 읽기, 쓰기 권한)이며, 사용할 크기는 200G 입니다.
이렇게 생성된 pvc는 동적 프로비저닝에 의해 pv가 생성되고 binding 합니다.
생성된 pvc를 pod에 사용하는 방법은 아래와 같습니다.
apiVersion: apps/v1 kind: StatefulSet metadata: name: devainexus ... containers: - name: devainexus ... volumeMounts: - name: data mountPath: /nexus-data subPath: "nexus" volumes: - name: data persistentVolumeClaim: claimName: nexus-data-volume
container의 volume mount를 설정해준 뒤, volumes에 해당 mount의 정보를 작성합니다.
pvc를 사용할 것이고, 사용할 pvc의 이름은 nexus-data-volume임을 확인할 수 있습니다.
마무리
- k8s에서 제공하는 볼륨 중 pv와 pvc에 대해 알아보았습니다.
아티클이 유용했나요?
훌륭합니다!
피드백을 제공해 주셔서 감사합니다.
도움이 되지 못해 죄송합니다!
피드백을 제공해 주셔서 감사합니다.
피드백 전송
소중한 의견을 수렴하여 아티클을 개선하도록 노력하겠습니다.