Introduction
본 과정은 AWS EBS CSI Driver 설치 및 구성이 완료된 상태에서 진행합니다.
정적 프로비저닝
다음과 같은 진행 과정을 통해 AWS EBS를 통해서 PV를 직접 생성하는 정적 프로비저닝을 구성해 보자.
실습
이번 실습에서 전체 만들고자 하는 구성 정보는 다음과 같다.
자! 그럼 바로 시작해 보도록 하자. 🛫
EBS 볼륨 수동 생성
aws 명령어를 통해서 EBS 볼륨을 생성하고, 확인한다.
// EBS 볼륨 생성 - 가용 영역: ap-northeast-2c
aws ec2 create-volume \
--size 5 \
--availability-zone ap-northeast-2c \
--volume-type gp3 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=static-ebs-vol}]'
// EBS 볼륨 ID 변수 선언
EBS_ID=$(aws ec2 describe-volumes --query "Volumes[?Tags[?Value=='static-ebs-vol']].[VolumeId]" --output text); echo $EBS_ID
// 생성된 EBS 볼륨 확인
aws ec2 describe-volumes --volume-ids $EBS_ID | jq다음과 같이 EC2의 볼륨탭을 들어가보면 EBS 볼륨이 생성된 것을 확인할 수 있다.
우리는 이를 이용해서 PV를 생성하도록 할 것이다.
정적 프로비저닝 - PV 생성
💡정적 프로비저닝은 PV를 직접 생성한다는 의미이다.
PV를 직접 생성할 때 EBS 볼륨 ID를 넣어 생성해 주면 된다.
// yaml 파일 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/cloudneta/cnaeblab/master/_data/ebs_sp_pv.yaml
cat ebs_sp_pv.yaml | yh
// EBS 볼륨 ID 변경
sed -i "s/vol-01234567890123456/$EBS_ID/g" ebs_sp_pv.yaml; cat ebs_sp_pv.yaml | yh
// PV 생성
kubectl apply -f ebs_sp_pv.yaml
// PV 정보 확인
kubectl describe pv | yh
파드가 저거 레이블 들고있노?
정적 프로비저닝 - PVC 생성
// yaml 파일 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/cloudneta/cnaeblab/master/_data/ebs_sp_pvc.yaml
cat ebs_sp_pvc.yaml | yh
// PVC 생성
kubectl apply -f ebs_sp_pvc.yaml
PVC는 사실 정적 프로비저닝이므로 별 거 없다.
PVC를 생성하게 되면 accessModes와 storage에 맞는 PV를 찾아 자동으로 바인드된 것을 확인할 수 있다.
정적 프로비저닝 - 파드 생성
// yaml 파일 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/cloudneta/cnaeblab/master/_data/ebs_sp_pod.yaml
cat ebs_sp_pod.yaml | yh
// 파드 생성
kubectl apply -f ebs_sp_pod.yaml파드를 생성할 때, Volumes에 정의된 PVC를 통해서 EBS로 생성한 PV와 파드가 마운트된다.
이것으로 정적 프로비저닝이 완료되었다.👏🏻
볼륨 정보 확인
// VolumeAttachment 확인
kubectl get VolumeAttachment
// 파드에서 마운트 대상의 디스크 사용 확인
kubectl exec -it ebs-sp-app -- sh -c 'df -hT --type=ext4'
// 클러스터 내 모든 PV의 디스크 사용 확인 (krew tool)
kubectl df-pvkubectl get VolumeAttachment를 통해서 AWS CSI Driver를 통해 어떤 AWS 볼륨이 연결되었는 지 확인할 수 있다.
파드 내 PV가 잘 마운트되어 사용 중인지도 확인할 수 있다.
파드에서 데이터 확인
// 파드에서 out.txt 파일 확인
kubectl exec ebs-sp-app -- tail -f /data/out.txt
// 컨테이너 프로세스 강제 종료 후 재시작
kubectl exec ebs-sp-app -c app -- kill -s SIGINT 1
// 파드에서 out.txt 파일 확인
kubectl exec ebs-sp-app -- tail -f /data/out.txtEBS PV는 컨테이너의 생명주기와 관련이 없으므로, 컨테이너가 죽던지 말던지 상관없이 여전히 데이터가 💍영속적으로 유지된다.
파드 재생성 후 확인
// 파드 삭제 후 재생성
kubectl delete pod ebs-sp-app
kubectl apply -f ebs_sp_pod.yaml
// 파드에서 out.txt 파일 확인
kubectl exec ebs-sp-app -- tail -f /data/out.txtEBS PV는 파드의 생명주기와도 관련이 없으므로, 파드가 죽던지 말던지 상관없이 여전히 데이터가 💍영속적으로 유지된다.
💡
Tip: PV의 ReclaimPolicy가 Retain인 경우
PVC를 삭제하면 PV는 Released 상태로 전환되는데 현재 볼륨을 보존한 상태로 사용 가능한 상태가 아니다. 즉, PVC를 다시 생성해도 해당 PV를 사용할 수 없는 것으로 PV 상태를 강제로 Available 상태로 전환시켜야 한다.
kubectl patch pv ebs-sp-pv -p ‘{“spec”:{“claimRef”: null}}’
동적 프로비저닝
다음과 같은 진행 과정을 통해 AWS EBS를 통해서 PV를 StorageClass를 통해 자동으로 생성하는 동적 프로비저닝을 구성해 보자.
실습
자! 그럼 바로 시작해 보도록 하자. 🛫
StorageClass 생성
// yaml 파일 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/cloudneta/cnaeblab/master/_data/ebs_dp_sc.yaml
cat ebs_dp_sc.yaml | yh
// StorageClass 생성
kubectl apply -f ebs_dp_sc.yaml동적 프로비저닝을 위한 StorageClass를 정의하고 생성한다. 이때, 프로비저너로 EBS CSI Driver를 사용한다.
PVC 생성
// yaml 파일 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/cloudneta/cnaeblab/master/_data/ebs_dp_pvc.yaml
cat ebs_dp_pvc.yaml | yh
// PVC 생성
kubectl apply -f ebs_dp_pvc.yamlPVC에 정적 프로비저닝과는 다르게 StorageClass가 추가되었다.
파드 생성
// yaml 파일 다운로드 및 확인
curl -s -O https://raw.githubusercontent.com/cloudneta/cnaeblab/master/_data/ebs_dp_pod.yaml
cat ebs_dp_pod.yaml | yh
// 파드 생성
kubectl apply -f ebs_dp_pod.yamlPVC를 통해서 EBS 볼륨에 마운트하게되고, 이 과정에서 자동으로 PV가 생성되어 PVC와 바인드 된다.
당연히 EBS는 가용영역에 종속적이므로 해당 PV는 파드의 가용영역(노드 위치)에 생성되게 된다.
- 동적으로 생성된 PV (AWS EBS)
G
이것으로 동적 프로비저닝 과정을 마친다.🔚
이제 추가적으로 구성된 동적 프로비저닝 환경을 확인해보자.
ebs-csi-controller의 provisioner 로그 확인
kubectl get pod -n kube-system
// ebs-csi-controller 이름 변수 선언
CSI_CTR_1=$(kubectl get pod -n kube-system -l app=ebs-csi-controller -o jsonpath='{.items[0].metadata.name}') ; echo $CSI_CTR_1
CSI_CTR_2=$(kubectl get pod -n kube-system -l app=ebs-csi-controller -o jsonpath='{.items[1].metadata.name}') ; echo $CSI_CTR_2
// ebs-csi-controller의 provisioner 로그 확인 (Primary ebs-csi-controller 대상에서 확인)
kubectl logs $CSI_CTR_1 -n kube-system -c csi-provisioner --tail 10
or
kubectl logs $CSI_CTR_2 -n kube-system -c csi-provisioner --tail 10ebs-csi-controller가 두개가 생성되는데 이 두개 중 하나가 리더로 선정되고, 해당 프로비저너만 주 파드로 동작된다.
어떤 게 진짜인지 모르니 두개 다 csi-provisioner 컨테이너의 로그를 찍어보자.
Provisioner가 열심히 PVC에 따라서 PV를 프로비저닝하고, Controller를 통해 실제 EBS스토리지로 부터 볼륨을 생성하는 것을 확인할 수 있다.
ebs-csi-controller의 attacher 로그 확인
// ebs-csi-controller의 attacher 로그 확인 (Primary ebs-csi-controller 대상에서 확인)
kubectl logs $CSI_CTR_1 -n kube-system -c csi-attacher --tail 10
kubectl logs $CSI_CTR_2 -n kube-system -c csi-attacher --tail 10
// VolumeAttachment 확인
kubectl get VolumeAttachment
attacher의 로그에 나온 정보와 VolumeAttachment의 이름이 동일한 것을 확인할 수 있다.
볼륨 확인
// 파드에서 마운트 대상의 디스크 사용 확인
kubectl exec -it ebs-dp-app -- sh -c 'df -hT --type=ext4'
// 클러스터 내 PV의 디스크 사용 확인 (krew tool)
kubectl df-pv
파드에서 데이터 확인
// 파드에서 out.txt 파일 확인
kubectl exec ebs-dp-app -- tail -f /data/out.txt
스토리지 용량 증가
만일 볼륨의 사이즈를 증가시키고 싶다면 어떻게 해야할까?🆙
// pvc에 정의된 스토리지 용량
kubectl get pvc ebs-dp-claim -o jsonpath={.status.capacity.storage} ; echo
// pvc에 정의된 스토리지 용량을 증가 (4Gi -> 10Gi)
kubectl patch pvc ebs-dp-claim -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}'먼저 StorageClass를 정의할 때 Allow 값이 True로 설정되어야 수정이 가능하다.
이후 PVC를 수정하게되면 자동으로 Controller 노드의 resizer✂️에 의해서 PV의 용량이 변경된다.
⚠️단, 용량의 축소는 불가능하다!
변경 후 확인
// 파드에서 마운트 대상의 디스크 사용 확인
kubectl exec -it ebs-dp-app -- sh -c 'df -hT --type=ext4'
// 클러스터 내 PV의 디스크 사용 확인 (krew tool)
kubectl df-pv10G로 증가한 것을 확인할 수 있다.
ebs-csi-controller의 resizer 로그 확인
이러한 PVC를 수정해서 확장하는 작업은 resizer✂️ 컨테이너가 수행한다.
resizer✂️ 컨테이너의 로그를 확인해 보면 다음과 같다.
// ebs-csi-controller의 resizer 로그 확인 (Primary ebs-csi-controller 대상에서 확인)
kubectl logs $CSI_CTR_1 -n kube-system -c csi-resizer --tail 10
or
kubectl logs $CSI_CTR_2 -n kube-system -c csi-resizer --tail 10
로그를 보면 PV의 용량을 확장했다는 로그가 나오고 이후 볼륨에 마운트된 파일 시스템 또한 확장되어야 하므로FileSystemResizeRequired 즉, 실제 EBS 스토리지 영역 또한 확장하라는 요청이 들어온 것을 확인할 수 있다.
- AWS EBS가 수정된 결과
