퍼시스턴트 볼륨(PV)와 퍼시스턴트 볼륨 클레임(PVC)
데이터베이스처럼 파드 내부에서 특정 데이터를 보유해야 하는 상태가 있는(stateful) 애플리케이션의 경우 데이터를 어떻게 관리해야 할까 고민해봐야 한다. 예를 들어, MySQL 디플로이먼트를 통해 파드를 생성하더라도 MySQL 파드 내부에 저장된 데이터는 영속적이지 않다.
디플로이먼트를 삭제하면 파드도 함께 삭제되고 그와 동시에 파드의 데이터 또한 함께 삭제되기 때문이다.
이를 해결하기 위해서 파드의 데이터를 영속적으로 저장하기 위한 방법이 필요하다.
쿠버네티스는 워커 노드 중 하나를 선택해 파드를 할당하는데, 특정 노드에서만 데이터를 보관해 저장하면 파드가 다른 노드로 옮겨갔을 때 해당 데이터를 사용할 수 없게 되기 이를 해결하기 위한 일반적인 방법은 어느 노드에서도 접근해 사용할 수 있는 퍼시스턴트 볼륨을 사용하는 방법이다.
PV는 워커 노드들이 네트워크 상에서 스토리지를 마운트해 영속적으로 데이터를 저장할 수 있는 볼륨을 의미한다. 따라서 파드에 장애가 생겨 다른 노드로 옮겨가더라도 해당 노드에서 PV에 네트워크로 연결해 데이터를 계속해서 사용할 수 있다.
네트워크로 연결해 사용할 수 있는 PV의 대표적인 예로는 NFS, AWS의 EBS, Ceph, ClusterFS 등이 있다.
쿠버네티스는 PV를 사용하기 위한 기능을 자체적으로 제공하고 있다.
로컬 볼륨: hostPath, emptyDir
hostPath는 호스트와 볼륨을 공유하기 위해서 사용하고, emptyDir은 파드의 컨테이너 간에 볼륨을 공유하기 위해서 사용한다. 이 두가지는 자주 사용되는 볼륨 종류는 아니긴 하다.
워커 노드의 로컬 디렉토리를 볼륨으로 사용: hostPath
파드의 데이터를 보존할 수 있는 가장 간단한 방법은 호스트의 디렉토리를 파드와 공유해 데이터를 저장하는 방법이다. docker 의 -v 옵션이라고 생각하면 된다.
volumes 항목에 볼륨을 정의한 뒤, 이를 파드를 정의하는 containers 항목에 참조해 사용한다. 위 예시에서는 볼륨에서 hostPath 항목을 정의함으로써 호스트의 /tmp 디렉토리를 파드의 /etc/data 에 마운트했다.
파드를 생성한 뒤 파드의 컨테이너 내부로 들어가 /etc/data 디렉토리에 파일을 생성하면 호스트의 /tmp 디렉토리에 파일이 저장된다. 파드 컨테이너의 /etc/data와 호스트의 /tmp는 동일한 디렉토리로써 사용된다.
$ kubectl exec -it hostpath-pod touch /etc/data/mydata
$ ls /tmp/mydata
/tmp/mydata
이런 방식의 데이터 보존은 바람직하지 않다. 디플로이먼트의 파드에 장애가 생겨 다른 노드로 파드가 옮겨 갔을 경우 이전 노드에 저장된 데이터를 사용할 수 없기 때문이다.
hostPath 볼륨을 반드시 사용해야 한다면 노드 스케줄링 기능을 사용하여 특정 노드에만 파드를 배치하는 방법을 생각해봐야 한다.
hostPath 볼륨은 모든 노드에 배치해야 하는 특수한 파드의 경우에 유용하게 사용할 수 있다. 만약, CAdvisior와 같은 모니터링 툴을 쿠버네티스의 모든 워커 노드에 배포해야 한다면 hostPath 를 사용하는 것이 옳은 선택이다. 이런 경우를 제외하고서는 hostPath 볼륨을 사용하는 것은 보안 및 활용성 측면에서 바람직한 방법이 아니다.
파드 내의 컨테이너 간 임시 데이터 공유: emptyDir
emptyDir 볼륨은 파드의 데이터를 영속적으로 보존하기 위해 외부 볼륨을 사용하는 것이 아닌, 파드가 실행되는 도중에만 필요한 휘발성 데이터를 각 컨테이너가 함께 사용할 수 있도록 임시 저장 공간을 생성한다.
emptyDir 이라는 이름이 의미하는 것처럼 emptyDir 디렉토리는 비어있는 상태로 생성되며 파드가 삭제되면 emptyDir에 저장돼 있던 데이터도 함께 삭제된다.
emptyDir 은 한 컨테이너가 파일을 관리하고 한 컨테이너가 그 파일을 사용하는 경우 유용하게 사용할 수 있다. content-creator 컨테이너 내부로 들어가 /data 디렉토리에 웹 컨텐츠를 생성하면 아파치 웹 서버 컨테이너의 htdocs 디렉토리에도 동일하게 웹 컨텐츠 파일이 생성될 것이고, 웹 서버에 의해 외부로 제공된다.
$ kubectl exec -it emptyDir-pod -c content-creator sh
/ # echo Hello, World! >> /data/test.html
이런 방법외에도 깃허브 소스코드를 pull 받아와서 emptyDir을 통해 애플리케이션 컨테이너에 공유해주는 사이드카 컨테이너를 생각할 수도 있고 설정 파일을 동적으로 갱신하는 컨테이너를 파드에 포함시킬 수도 있다.
네트워크 볼륨
쿠버네티스에서는 별도의 플러그인을 설치하지 않아도 다양한 종류의 네트워크 볼륨을 파드에 마운트할 수 있다. 온프레미스 환경에서도 구축할 수 있는 NFS, iSCSI, GlusterFS, Ceph 와 같은 네트워크 볼륨뿐만 아니라 AWS의 EBS, GCP의 gcePersistentDisk 와 같은 클라우드 플랫폼의 볼륨을 마운트할 수 있다.
사용 가능한 모든 스토리지 종류는 쿠버네티스 공식 문서에서 확인할 수 있다.
네트워크 볼륨의 위치는 특별하게 정해진 것은 없고, 네트워크로 접근할 수 만 있으면 쿠버네티스 클러스터 내부, 외부 어느 곳에 존재해도 상관없다. 단, AWS의 EBS와 같은 클라우드에 종속적인 볼륨을 사용하려면 AWS에서 쿠버네티스 클러스터를 생성할 때 특정 클라우드를 위한 옵션이 별도로 설정돼 있어야 한다.
NFS를 네트워크 볼륨으로 사용하기
여러 개의 클라이언트가 동시에 마운트해서 사용할 수 있지만 여러 개의 스토리지를 클러스터링하는 다른 솔루션에 비해 안정성이 떨어진다. 하지만 하나의 서버만으로 간편하게 사용할 수 있으며, NFS를 마치 로컬 스토리지처럼 사용할 수 있다는 장점이 있다.
NFS 서버를 사용하려면 NFS 서버와 NFS 클라이언트가 각각 필요하다. NFS 서버는 영속적인 데이터가 실제로 저장되는 네트워크 스토리지 서버이고, NFS 클라이언트는 NFS 서버에 마운트해 스토리지에 파일을 읽고 쓰는 역할이다. NFS 클라이언트는 워커 노드의 기능을 사용할 것이기 때문에 따로 준비할 필요는 없고 NFS 서버만 별도로 구축하면 된다.
NFS 서버를 위한 디플로이먼트와 서비스를 생성했고, NFS 서버의 볼륨을 파드에서 마운트해 데이터를 영속적으로 저장시킨다.
NFS 서버를 컨테이너에서 마운트하는 파드를 생성한다.
mountPath를 /mnt로 설정했기 때문에 NFS 서버의 네트워크 볼륨은 파드 컨테이너의 /mnt 디렉토리에 마운트 될 것이다. 즉, 컨테이너 내부에서 /mnt 디렉토리에 파일을 저장하면 NFS 서버에 데이터가 저장된다.
volumes 항목에서 nfs 라는 항목을 정의함으로써 NFS 서버의 볼륨을 사용한다고 명시했다.
여기 예제에서 유의해야 할 부분은 server 항목이 nfs-service라는 서비스의 DNS 이름이 아닌 {NFS_SERVICE_IP}로 설정돼 있다는 것이다. NFS 볼륨의 마운트는 컨테이너 내부가 아닌 워커 노드에서 발생하므로 서비스의 DNS 이름으로 NFS 서버에 접근할 수 없다.
노드에서는 파드의 IP로 통신은 할 수 있지만 쿠버네티스의 DNS를 사용하도록 설정돼 있지 않기 때문이다.
그래서 예외적으로 NFS 서비스의 Cluster IP 를 직접 얻은 뒤, YAML 파일에서 사용하는 방식으로 파드를 생성한다.
$ export NFS_CLUSTER_IP=$(kubectl get svc nfs-service -o jsonpath='{.spec.clusterIP}')
$ cat nfs-pod.yaml | sed "s/{NFS_SERVICE_IP}/$NFS_CLUSTER_IP/g" | kubectl apply -f -
kubectl get - o jsonpath 명령어를 사용하여 리소스의 특정 정보만 가져올 수 있다.
NFS 서버에 마운트하려면 워커 노드에서 별도의 NFS 패키지를 설치해야 할 수도 있다. 만약 파드가 ContainerCreating 상태에서 더 이상 진행되지 않는다면 kubectl describe pod 명령어로 문제를 확인하고 파드가 할당된 워커 노드에서 $ apt-get install nfs-common 패키지를 설치한다.
실제 운영환경에서 NFS 서버를 도입하려면 백업 스토리지를 별도로 구축해 NFS의 데이터 손실에 대비하거나 NFS 서버의 설정 튜닝 및 NFS 서버에 접근하기 위한 DNS 이름을 준비해야 할 수도 있다. 이런 설정들은 환경에 맞게 적절히 구성해야 한다.
PV, PVC를 이용한 볼륨 관리
PV와 PVC를 사용하는 이유
PVC 는 PV의 세부적인 사항을 몰라도 볼륨을 사용할 수 있도록 추상화해주는 역할을 담당한다. 즉, 파드를 생성하는 YAML 입장에서는 네트워크 볼륨이 NFS인지, AWS의 EBS인지 상관없이 볼륨을 사용할 수 있도록 하는 것이 PVC의 핵심 아이디어이다.
PV와 PVC를 사용하는 흐름을 간단하게 나타내면 아래와 같다.
- 여러 종류의 네트워크 볼륨을 이용해 PV를 미리 생성한다.
- 필요한 볼륨 크기, 볼륨의 속성을 명시한 PVC 를 생성한다.
- PVC 요청에 부합하는 PV를 바인드해 컨테이너에 마운트한다.
위 과정에서 중요한 점은 ‘사용자는 디플로이먼트의 YAML 파일에 볼륨의 상세한 스펙을 정의하지 않아도 된다는 것이다.’ 사용자는 YAML 파일에서 이 디플로이먼트는 볼륨을 마운트할 수 있어야 한다는 의미의 퍼시스턴트 볼륨 클레임을 명시할 뿐이고, 실제로 마운트되는 볼륨이 무엇인지 알 필요가 없다.
AWS에서 PV, PVC 사용
AWS 상에서 kops 나 EKS 로 쿠버네티스를 설치했다면 PV를 EBS와 연동해 사용할 수 있다.
AWS에서 EBS를 쿠버네티스의 PV로 등록하려면 가장 먼저 EBS를 생성해야 한다. AWS 웹사이트 관리 콘솔에서 EBS를 생성해도 상관없지만 여기서는 aws-cli 명령어를 사용해 EBS를 생성한다.
--size 옵션에서는 볼륨의 크기를 기가바이트(GB) 단위로 입력한다. 다음 명령어는 5기가의 EBS 볼륨을 생성하는 예이다.
$ export VOLUME_ID=$(aws ec2 create-volume --size 5
--region ap-northeast-2
--availability-zone ap-northeast-2a
--volum-type gp2
--tag-specifications
'ResourceType=volume, Tags=[{Key=KubernetesCluster,Value=mycluster.k8s.local}]'
| jq '.VolumeId' -r)
$ echo $VOLUME_ID
vol-xxxx...
EBS의 볼륨 ID를 $VOLUME_ID라는 셸 변수에 저장하고 이 ID를 통해 PV를 생성한다.
EBS의 가용 영역과 리전은 반드시 쿠버네티스 워커 노드와 동일한 곳에 있어야 한다.
AWS의 EBS를 마운트하기 위해 awsElasticBlockStore라는 항목을 정의했다. 볼륨의 타입에 따라 하위 항목에 정의하는 옵션이 달라질 수 있으며, EBS의 볼륨 ID를 입력해야 한다.
$ cat ebs-pv.yaml | sed "s/<VOLUME_ID>/$VOLUME_ID/g" | kubectl apply -f -
PVC 를 생성하지 않았기 때문에 STATUS 항목이 Avaliable 로 설정된다.
애플리케이션을 배포하려는 사용자 입장에서 PV, PVC 파드를 함께 생성한다. PVC 오브젝트를 먼저 생성한 뒤 이를 파드의 volumes 항목에서 사용함으로써 파드 내부에 EBS 볼륨을 마운트한다.
PVC 의 요구 사항과 일치하는 PV 가 존재하지 않는다면 파드는 계속해서 Pending 상태로 남아있는다.
PV와 PVC 상태가 bound로 설정됐다면 두 리소스가 성공적으로 연결된 것이다. 파드가 정상적으로 생성되어 Running 상태라면 EBS 볼륨 또한 파드 내부에 정상적으로 마운트됐다는 뜻이다.
PV는 네임 스페이스에 속하지 않는 오브젝트이지만, PVC는 네임스페이스에 속하는 오브젝트이다.
위 과정을 다시 순차적으로 나타내면 아래와 같다.
- 파드의 데이터를 영속적으로 저장하기 위해 AWS EBS 볼륨을 생성한다. awscli 나 콘솔에서 직접 생성한 뒤 볼륨의 ID를 기록한다.
- EBS 볼륨을 쿠버네티스 PV로 등록한다. 이 때 YAML 파일에 awsElasticBlockStore 항목에 EBS 볼륨 ID를 명시한다. 또한 볼륨의 읽기 및 쓰기 속성, 볼륨의 크기를 별도로 설정한다.
- PVC 생성하는 YAML 파일에 원하는 볼륨의 조건을 나열한다.
- PV 속성이 PVC의 요구 조건과 일치할 경우 리소스가 연결된다. kubectl get pv,pvc 출력 결과를 확인하면 리소스의 상태가 Bound 즉, 연결 상태로 바뀌는 것을 확인할 수 있다.
- 파드는 PVC 를 사용하도록 설정돼 있고 최종적으로 EBS 볼륨이 컨테이너 내부에 마운트된다.
PV 를 선택하기 위한 조건 명시
PVC 를 사용하면 볼륨이 어떤 스펙을 가졌는지 알 필요는 없지만 사용하려는 볼륨이 애플리케이션에 필요한 최소한의 조건을 맞출 필요는 있다.
볼륨의 크기가 적어도 얼마나 돼야 하는지, 여러 개의 파드에 마운트 될 수 있는지, 읽기 전용으로만 사용할 수 있는지 등이 조건에 해당할 수 있다.
AccessMode나 볼륨의 크기 등이 바로 이런 조건에 해당한다. PV와 PVC의 accessMode 및 볼륨 크기 속성이 부합해야만 쿠버네티스는 두 리소스를 매칭해 바인드한다.
NFS 는 여러 개의 인스턴스에 의해 마운트가 가능하지만(1:N 마운트), AWS의 EBS는 하나의 인스턴스에 의해서만 마운트될 수 있다(1:1 마운트). 또한, NFS 서버의 저장 공간 크기는 일반적으로 호스트의 스토리지 크기와 동일하지만, AWS의 EBS는 생성 당시에 설정했던 크기만큼만 데이터를 저장할 수 있다.
AccessModes와 볼륨 크기, 스토리지 클래스, 라벨 셀렉터를 이용한 PV 선택
accessModes는 PV와 PVC를 생성할 때 설정할 수 있는 속성으로 볼륨에 대해 읽기 및 쓰기 작업이 가능하지, 여러 개의 인스턴스에 의해 마운트 될 수 있는지 등을 의미한다. 사용 가능한 accessModes 의 종류는 아래와 같다.
- ReadWriteOnce: 1:1 마운트만 가능, 읽기 쓰기 가능, RWO 로 출력
- ReadOnlyMany: 1:N 마운트 가능, 읽기 전용, ROX 로 출력
- ReadWriteMany: 1:N 마운트 가능, 읽기 쓰기 가능, RWX 로 출력
accesModes 나 볼륨의 크기는 해당 볼륨의 메타데이터일 뿐, 볼륨이 정말로 그러한 속성을 가지도록 강제하지는 않는다. 예를 들어 AWS의 EBS를 통해 PV를 생성하더라도 accessModes를 ReadWriteMany로 설정할 수 있다.
Local, hostPath 등 로컬 볼륨을 PV로 사용할 수 있는데, 그러한 경우 YAML 파일의 capacity.storage 항목에 크기를 지정한다고 해서 해당 크기의 새 디스크 파티션이 생성되는 것도 아니다. 따라서 이런 설정들은 애플리케이션을 배포할 때 적절한 볼륨을 찾아주는 라벨과 같은 역할을 한다고 생각하면 된다.
그 외에도 스토리지 클래스나 라벨 셀렉터를 이용해 PV의 선택을 좀 더 세분화할 수 있다. 스토리지 클래스는 볼륨의 대표 속성 등을 나타내는 것으로, PV를 생성할 때 클래스를 설정하면 해당 클래스를 요청하는 PVC와 연결해 바인드한다.
위의 두 개의 YAML에서는 각각 storageClassName 이라는 항목에 my-ebs-volume 이라는 값을 입력했다. 이러한 경우 스토리지 클래스의 이름이 일치하는 PV와 PVC이 서로 연결된다.
단, storageClassName을 별도로 YAML 파일에 명시하지 않으면 클래스가 설정되지 않았다는 뜻 인 ”” 으로 설정되며 똑같이 스토리지 클래스가 설정되지 않은 PV 또는 PVC와 매칭된다.
또는 라벨 셀렉터를 사용할 수도 있다. 서비스와 디플로이먼트를 서로 연결할 때 라벨 셀렉터를 사용했던 것처럼 PVC에 라벨 셀렉터인 matchLabels 항목을 정의함으로써 특정 PV와 바인드하는 것이 가능하다.
PV의 라이프 사이클과 Reclaim Policy
PV 를 정상적으로 생성하고 STATUS 부분을 확인하면 Avaliable 로 되어있는 것을 확인할 수 있다. STATUS라는 항목은 PV가 사용 가능한지, PVC와 연결됐는지 등을 의미한다.
PVC를 새로 생성하여 바인드했을 때는 STATUS 항목이 Bound(연결됨)로 바뀌는 것을 확인할 수 있다. PV가 이미 바인드 됐기 때문에 다른 PVC 와 연결할 수 없는 상태이다.
PV와 연결된 PVC를 삭제할 경우 직관적으로 생각하면 PVC 가 없어졌으니 연결된 PV를 다시 사용할 수 있을 것처럼 생각할 수 있다.
PVC 를 삭제하면 PV의 STATUS가 Available 이 아닌 Released 상태로 변경된다. Released 는 해당 PV의 사용이 끝났다는 것을 의미하며, Released 상태에 있는 PV는 다시 사용할 수 없다.
그렇지만 실제 데이터는 볼륨 안에 고스란히 보존돼 있기 때문에 PV 오브젝트를 삭제한 뒤 다시 생성하면 Avaliable 상태의 볼륨을 다시 사용할 수 있다.
하지만, PVC를 삭제했을 때, PV의 데이터를 어떻게 처리할 것인지 별도로 정의할 수도 있다. PV 사용이 끝났을 때 해당 볼륨을 어떻게 초기화 할 것인지 별도로 설정할 수 있는데 쿠버네티스는 이를 Reclaim Policy라고 부른다. 크게 Retain, Delete, Recycle 방식이 존재한다.
보통 PV의 용도는 데이터를 영구적으로 저장하기 위한 것이기 때문에 PV 사용이 끝난 뒤에도 원격 스토리지에 저장된 데이터를 계속해서 보존하고 싶을 것이다. 쿠버네티스는 기본적으로 PV 데이터를 보존하는 방식인 Retain 방식이 기본값으로 사용한다.
kubectl get pv 명령어에서 출력되는 RECLAIM POLICY 항목의 Retain 이라는 설정값이 이를 뜻한다.
PV 라이프 사이클에 대한 아무런 설정을 하지 않았다면 즉, PV 의 Reclaim Policy가 기본값인 Retain 으로 설정돼 있다면 PV 의 라이프 사이클은 Available → Bound → Released 가 된다.
Reclaim Policy 가 Retain으로 설정된 PV는 연결된 PVC가 삭제된 후 Released 상태로 전환되며, 스토리지에 저장된 데이터는 그대로 보존된다.
Retain 과 반대의 역할을 하는 Delete, Recycle 정책이 있다. PV 의 리클레임 정책을 Delete 로 설정해 생성했다면 PV의 사용이 끝난 뒤에 자동으로 PV가 삭제되며, 가능한 경우에 한해서 연결된 외부 스토리지도 함께 삭제된다.
$ cat ebs-pv-delete.yaml | sed "s/<VOLUME_ID>/$VOLUME_ID/g" | kubectl apply -f -
리클레임 정책이 Delete 인 PV를 파드 내부에 마운트한 뒤 PVC 를 삭제함으로써 사용을 종료할 경우, 리클레임 정책이 Delete 이기 때문에 PVC가 삭제됨과 동시에 PV가 삭제된다. 그 뿐만 아니라 외부에 연결돼 있던 EBS 볼륨도 한꺼번에 삭제되기 매누에 볼륨에 저장돼 있던 파일들이 모두 유실된다.
Recycle 정책은 PVC 가 삭제됐을 때 PV 데이터를 모두 삭제한 뒤, Available 상태로 만들어준다. 이 정책은 Delete 와 다르게 PV나 외부 스토리지 자체를 삭제하지는 않는다. Recycle 정책은 쿠버네티스에서 더 이상 사용되지 않을 정책 중 하나이다.
storageClass와 Dynamic Provisioning
PV를 사용하려면 미리 외부 스토리지를 준비해야만 했다. AWS의 EBS를 PV로 사용하려면 EBS를 미리 생성한 뒤, 볼륨 ID를 YAML 파일에 직접 입력하는 방식이었다.
매번 이렇게 볼륨 스토리지를 직접 수동으로 생성하고 스토리지에 대한 접근 정보를 YAML 파일에 적는 것은 귀찮은 일이다.
이를 위해 쿠버네티스는 동적 프로비저닝이라는 기능을 제공한다. 동적 프로비저닝은 PVC가 요구하는 조건과 일치하는 PV가 존재하지 않는다면 자동으로 PV와 외부 스토리지를 함께 프로비저닝하는 기능이다.
따라서 동적 프로비저닝을 사용하면 EBS와 같은 외부 스토리지를 직접 미리 생성할 필요가 없으며 PVC를 생성하면 외부 스토리지가 자동으로 생성되기 때문이다.
앞서 특정 PV를 선택하기 위해 스토리지 클래스를 사용했던 것처럼 동적 프로비저닝에서도 사용할 수 있다. 동적 프로비저닝은 스토리지 클래스의 정보를 참고해 외부 스토리지를 생성하기 때문이다.
동적 프로비저닝의 예시를 단계별로 알아보자.
- ssd 라는 스토리지 클래스에는 SSD를 생성하라는 설정을, hdd라는 스토리지 클래스에는 HDD를 생성하라는 설정을 미리 정의했다고 가정한다.
- PVC에 특정 스토리지 클래스를 명시한다. PVC의 AccessModes나 Capacity 등의 조건과 일치하는 PV가 존재하지 않는 상태이다.
- 조건에 일치하는 PV를 새롭게 만들기 위해 스토리지 클래스에 정의된 속성에 따라서 외부 스토리지를 생성한다. 만약, PVC 에 storageClassName: ssd 로 설정했고, ssd라는 이름의 스토리지 클래스가 SSD에 대한 설정 정보를 담고 있다면 SSD 스토리지가 동적으로 생성된다.
- 새롭게 생성된 외부 스토리지는 쿠버네티스의 PV로 등록되고 PVC와 바인딩된다.
동적 프로비저닝을 모든 쿠버네티스 클러스터에서 범용적으로 사용할 수 있는 것은 아니며 동적 프로비저닝 기능이 지원되는 스토리지 프로비저너가 미리 활성화 돼 있어야 한다. 사용 가능한 프로비저닝 목록은 공식 문서에서 확인이 가능하다.
만약, AWS나 GCP와 같은 클라우드 플랫폼에서 쿠버네티스를 사용하고 있다면 별도로 설정하지 않아도 자동으로 동적 프로비저닝을 사용할 수 있다.
AWS에서 동적 프로비저닝 사용
provisioner와 type을 봐야 한다. provisioner 항목에는 AWS의 쿠버네티스에서 사용할 수 있는 EBS 동적 프로비저너인 kubernetes.io/aws-ebs를 설정했다. type 항목은 EBS가 어떤 종류인지 나타내는 것으로, st1과 gp2, sc1, io1 등을 사용할 수 있다.
PVC에 storageClassName 항목을 정의하지 않았을 때, 쿠버네티스에서 기본적으로 사용하도록 설정된 스토리지 클래스가 있다면 해당 스토리지 클래스를 통해 동적 프로비저닝이 수행된다. 따라서 동적 프로비저닝을 아예 사용하지 않을 것이라면 storageClassName: “” 으로 설정한다.
동적 프로비저닝을 사용할 때 주의해야 할 점은 PV의 리클레임 정책이 자동으로 Delete로 설정된다는 점이다. 동적으로 생성되는 PV의 리클레임 정책 속성은 스토리지 클래스에 설정된 reclaimPolicy 항목을 상속받는데, 스토리지 클래스의 reclaimPolicy는 기본적으로 Delete 이기 때문이다.
동적 프로비저닝에서 특정 스토리지 클래스를 기본값으로 사용
스토리지 클래스를 생성할 때, 아래와 같은 annotation 을 추가하면 이 스토리지 클래스를 기본값으로 사용한다.
$ kubectl get storageclass
NAME PROVISIONER AGE
HDD kubernetes.io/aws-ebs 3m27s
generic(default) kubernetes.io/aws-ebs 1s
SSD kubernetes.io/aws-ebs 3m42s