3W - kubestr과 EBS CSI 드라이버
개요
이번 글에서는 EKS에서 활용할 수 있는 각종 스토리지를 알아보고 관련한 기능 실습을 진행한다.
구체적으로는 EBS 드라이버를 활용할 건데, 여기에서 스냅샷을 만들고 활용하는 것을 실습할 것이다.
그리고 간단하게 스토리지 성능을 측정하는 kubestr을 써볼 건데, 이후 글에서 이를 활용하며 비교를 진행한다.
사전 지식
CSI
쿠버네티스에서는 다양한 환경에서 클러스터에 영속 스토리지를 세팅할 수 있도록 스토리지 인터페이스를 만들어뒀는데, 이것이 바로 Cluster Storage Interface, 즉 CSI이다.
이 스펙에 맞춰 다양한 CSI 드라이버들이 개발됐으며, AWS에서는 EBS CSI, EFS CSI, S3 CSI 등을 제작해 제공하고 있다.
무조건 csi에 국한되는 것은 아니지만, 이러한 인터페이스를 통해 만들어진 각종 드라이버들에 대해서 사용자는 스토리지 클래스를 만들 수 있다.
이로부터 동적 프로비저닝이 가능해며 보통 클러스터에서 스토리지를 쓴다고 하면 대체로 이런 방식으로 많이 활용한다.
스토리지 성능 측정 도구, kubestr
kubestr은 쿠버네티스 환경에서 스토리지 기능의 성능과 리스트를 탐색, 평가하는 툴이다.
- 현재 클러스터에 존재하는 스토리지 클래스, csi 드라이버를 찾아준다.
- 해당 스토리지가 제대로 설정됐고 동작하는지 체크한다.
- 해당 스토리지를 벤치마킹하여 지표를 알려준다.
이 툴을 이용하면 간단하게 iops, bandwidth 등을 측정할 수 있다.
kubestr은 스토리지 성능 측정 도구인 fio라는 툴을 내부적으로 이용한다.
그래서 fio 양식 파일을 이용해서 테스트를 진행할 수 있으며, 이를 잘 알아두면 활용할 때 도움이 될 것이다.
사용법은 실습에서 다룬다.
AWS EBS CSI Driver
AWS의 EBS를 스토리지로 사용할 수 있도록 도와주는 드라이버.
구조는 대충 이렇게 돼있다.[1]
모든 csi 드라이버가 이런 식의 구조를 띄는데, 각 노드에 마운팅을 담당하는 파드와 aws api에 요청을 보내는 컨트롤러 파드가 따로 존재한다.
이를 위해서 드라이버의 데몬셋 파드가 api를 온전히 사용해야 하며, 적절한 IAM 정책을 가지고 있어야만 한다.
만약 일련의 세팅 없이 애드온을 설치하게 되면 만들어진 PVC 이벤트에는 could not create volume in EC2: UnauthorizedOperation라는 에러가 뜨게 된다.
하나의 PV는 하나의 EBS 볼륨에 매칭된다.
EBS는 블록 스토리지이기에 블록 디바이스로 마운팅을 하는 것도 가능하고, 동적 볼륨 확장, 스냅샷 등의 많은 기능을 이용할 수 있다.
(구체적으로는 aws에서 인터페이스에 맞게 기능들을 구현했다고 보는 것이 맞다.)
Volume Snapshot
데이터를 보존하는 전략 중 흔히 쓰이는 것 중 하나가 볼륨 스냅샷, 복제이다.
쿠버네티스에서도 이러한 기능을 제공하는데, 코어 api로 넣어두진 않았고 CRD로 설치할 수 있게 해두었다.
마치 Gateway API와 같은 식이다.
이 기능은 CS] 드라이버를 통한 볼륨에 대해서만 지원된다.
쿠버네티스에서는 CSI 인터페이스에 스냅샷과 관련된 사이드카 인터페이스까지 마련해주고 있기에 각 csi 드라이버가 이를 구현할 수 있다.
다시 정리해 말하자면, 이 기능을 지원하는 csi 드라이버를 설치해야 하고 관련 CRD를 설치해서 이용할 수 있다.
볼륨 스냅샷 관련 오브젝트는 크게 3가지가 있다.
미리 말하자면, 그냥 PV, PVC, 스토리지 클래스와 비슷한 개념을 가지고 있다.
VolumeSnapshotContent
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
spec:
deletionPolicy: Delete
driver: hostpath.csi.k8s.io
source:
volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
sourceVolumeMode: Filesystem
volumeSnapshotClassName: csi-hostpath-snapclass
volumeSnapshotRef:
name: new-snapshot-test
namespace: default
uid: 72d9a349-aacd-42d2-a240-d775650d2455
관리자에 의해 프로비저닝된 볼륨의 스냅샷이다.
PV와 같다고 할 수 있다.
위 예시는 동적으로 생성된 예시인데, source.volumeHandle에 CSI 드라이버에서 만들어준 볼륨 식별자가 담긴다.
volumeSnapshotRef 부분은 연결된 스냅샷이 있을 때 알아서 생성된다.
VolumeSnapshot
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: new-snapshot-test
spec:
volumeSnapshotClassName: csi-hostpath-snapclass
source:
persistentVolumeClaimName: pvc-test
유저에 의해 요청된 볼륨 스냅샷이다.
PVC와 같다고 할 수 있다.
위처럼 source 필드를 지정해서 원하는 오브젝트로부터 스냅샷을 뜬다.
이걸 바로 PVC에서 가져와서 볼륨을 만드는 것도 가능한데, PVC에서 dataSource 필드를 통해 사용할 수 있다.
VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: csi-hostpath-snapclass
annotations:
snapshot.storage.kubernetes.io/is-default-class: "true"
driver: hostpath.csi.k8s.io
deletionPolicy: Delete
parameters:
스냅샷을 요청할 때 사용할 수 있는 설정, 정의를 명시해둔 오브젝트로, 스토리지 클래스와 같다고 할 수 있다.
사용할 driver, deletionPolicy, parameters를 써주면 된다.
파라미터는 당연히 드라이버마다 다를 테니 각각의 드라이버를 참고해야 한다.
라이프 사이클
전반적인 동작은 이렇게 두 가지 방식으로 이뤄질 수 있다.
PV에 익숙하다면 그냥 똑같은 구조를 가지고 있다는 것을 알 수 있을 것이다.
스냅샷은 이러한 라이프사이클을 가지고 있다.
- 프로비저닝 - VolumeSnapshotContent가 만들어짐
- 정적 - 관리자가 직접 어떤 스냅샷을 클러스터 자원으로서 VolumelSnapshotContent로 만든다.
- 동적 - 유저가 존재하는 PVC에 대해 VolumeSnapshot를 요청한다.
- 이렇든 저렇든 VolumeSnapshotConent가 만들어진다.
- 바인딩 - VolumeSnapshot이 바인딩됨
- VolumeSnapshot과 VolumeSnapshot이 바인딩된다.
- 이 관계는 pv와 pvc처럼 1대1 관계이다.
- 동적의 경우, PVC가 스냅샷의 내용물이 되기 때문에 이 PVC는 스냅샷이 완전히 생성되기까지 보호된다.
- 삭제 - 삭제
- VolumeSnapshot의 삭제 요청이 일어나면 삭제 정책(DeletionPolicy)에 따라 자원의 유지가 결정된다.
스냅샷을 이용하면 필요한 데이터가 사고로 손실되는 위험성을 줄일 수 있다.
실습으로 볼 텐데, 스냅샷을 활용하면 한 가용영역에서만 사용가능한 EBS 볼륨을 여러 가용영역으로 복제하는 것도 가능하다.
(쿠버네티스의 볼륨 스냅샷 덕분에 가능한 건 아니고, 이런 꼼수도 있다 정도로만 생각하자.)
실습 진행
kubestr 설치
wget https://github.com/kastenhq/kubestr/releases/download/v0.4.48/kubestr_0.4.48_Linux_amd64.tar.gz
tar xvfz kubestr_0.4.48_Linux_amd64.tar.gz && mv kubestr /usr/local/bin/ && chmod +x /usr/local/bin/kubestr
kubectl 플러그인을 통해 설치를 지원하지는 않는 것으로 보이고, 알아서 설치를 할 수밖에 없다.
기본 설치를 하고 그냥 해당 명령어를 사용하면 현재 존재하는 스토리지 프로비저너와 그 상태를 확인할 수 있다.
세팅한 EKS에는 아무런 세팅 없이도 과거의 잔재인 인트리 EBS 프로비저너가 세팅은 돼있다.
이걸 이용해봐도 아무런 동작은 하지 않는다.
이 녀석은 kubernetes.io/로 시작하며 나중에 볼 ebs 드라이버가 사용하는 프로비저너 이름과 다르다.
로컬 프로비저너로 테스트
먼저 간단하게 로컬 프로비저너로도 동적으로 할 수 있도록 지원하는 프로젝트[2]를 활용해 테스트를 해보자.
이 프로비저너는 사이즈 제한을 지원하지도 않기에, 정말 실습용 그 이상 그 이하도 아니라고 개인적으로 생각한다.
아니면 정 동적으로 로컬 볼륨을 쓰고 싶을 때나 쓸 만할 것이다.
그래도 ConfigMap을 활용해 동적 설정 변경 기능을 지원하니, 연습하기에는 좋을 것이라 생각한다.
kubestr은 동적 프로비저닝 기능을 기반으로 테스트를 진행하기에, 로컬 환경의 테스트를 위해서는 이걸 세팅해야 한다.
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml
단순히 속도 측정을 위해 설치를 하기에 그냥 단순하게 설치한다.
이렇게 하면 local-path라는 이름의 스토리지 클래스가 생긴다.
kubestr fio -s local-path -z 10
이런 식으로 fio 명령어를 입력해 측정을 진행한다.
기본으로 진행된 테스트는 이렇다.
각 기본 세팅은 kubestr#fio 작성법에 담겨있는데, 간단하게만 지표를 보자면..
- read_iops
- block size 4k, 랜덤 읽기
- iops는 243, bw(대역폭)은 990
- read_bw
- block size 128k, 랜덤 읽기
- iops는 239, bw(대역폭)은 31241
- 블록 사이즈가 늘어남에 따라, 단위 전송량이 커졌고 이에 따라 iops는 소폭 하향 하는 대신 대역폭은 늘었다.
- write_iops
- block size 4k, 랜덤 쓰기
- iops는 216, bw(대역폭)은 880
- read_iops와 얼추 비슷한 성능으로 보인다.
- write_bw
- block size 128k, 랜덤 쓰기
- iops는 745, bw(대역폭)은 96021
- 블록 사이즈가 늘어났는데 iops가 증가했다.
- 이 부분에 대해
내부 캐시 및 쓰기 합병 효과 등을 활용, 오버헤드가 상대적으로 줄어들고 한 번에 더 많은 데이터가 전송라는 지피티의 답변이 있었다.
현재 사용되고 있는 블록은 gp3로, 최대 iops가 3000이며 처리량은 125로 설정돼있다.
write bw에서 iops가 더 높았다는 것은 조금 신기한데, 이론적으로는 블록 사이즈가 작을수록 iops가 높을 것이라 생각했기 때문이다.
[global]
ioengine=libaio
direct=1
bs=4k
runtime=120
time_based=1
iodepth=16
numjobs=16
group_reporting
size=1g
[read]
rw=randread
[write]
rw=randrw
rwmixread=0
rwmixwrite=100
name=write_iops
bs=4K
iodepth=64
size=2G
readwrite=randwrite
time_based
ramp_time=2s
runtime=15s
이번에는 스터디에서 제공해준 파일을 병합하여 테스트해본다.
크게 달라진 점은 numjobs의 수를 16으로 하여 병렬적으로 작업이 일어나게 했다는 것이다.
또 시간을 120초로 늘리고 direct=1을 설정하여 os 차원의 캐시는 발생하지 않는다.
이전 세팅과 동일하게 비동기 작업을 실행하는 대신 각 잡은 동시에 최대 16의 요청을 보내므로 256 개의 요청이 동시적으로 일어날 수 있다.
총체적으로는, 실제 디바이스에 행해지는 작업에 대해서 오랜 시간 결과를 수집하므로 비교적 안정적인 결과를 기대할 수 있을 것이다.
사진을 남겨두지 않았는데(..), 이렇게 진행하면 gp3 제한인 iops 3000과 유사한 값이 나온다.
대신 local path 기본 위치인 opt/local-path-provisoner 디렉토리에 들어가보면 이런 식으로 테스트가 진행되는 것을 확인할 수 있다.
EBS CSI 드라이버 세팅 및 테스트
나는 테라폼으로 환경을 구축하고 있는 관계로, 진행한 테라폼 세팅 방법을 싣고자 한다.
테라폼 세팅
resource "aws_eks_addon" "ebs-csi" {
cluster_name = module.eks.cluster_name
addon_name = "aws-ebs-csi-driver"
addon_version = "v1.39.0-eksbuild.1"
resolve_conflicts_on_update = "PRESERVE"
configuration_values = jsonencode({
defaultStorageClass = {
enabled = true
}
node = {
volumeAttachLimit = 31
enableMetrics = true
}
})
service_account_role_arn = module.ebs_csi_irsa.iam_role_arn
}
module "ebs_csi_irsa" {
source = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
version = "5.52.2"
attach_ebs_csi_policy = true
force_detach_policies = true
role_name = "ebs-csi"
oidc_providers = {
eks = {
provider_arn = module.eks.oidc_provider_arn
namespace_service_accounts = ["kube-system:ebs-csi-controller-sa"]
}
}
}
간단하게 클러스터가 세팅된 이후 테스트를 해본 이후, 테라폼으로 세팅을 옮겼다.
IRSA 설정을 간편하게 지원해주는 모듈이 있기에 이를 활용하면 편하게 세팅할 수 있다.
일일히 만들기 귀찮은 관계로, 기본 스토리지를 만드는 옵션을 추가해주었다.
구축 확인
세팅이 제대로 됐다면 데몬셋으로 각 노드에서 마운팅을 도와주는 파드와, aws api에 접근해 볼륨을 받아내는 컨트롤러가 배포되는 것을 확인할 수 있다.
재밌는 점은 윈도우를 위한 데몬셋도 같이 배포는 된다는 점인데, 아마 세팅에서 이건 바꿀 수 있지 않을까 한다.
k get daemonsets.apps ebs-csi-node -o jsonpath='{.spec.template.spec.containers[*].name}'
# ebs-plugin node-driver-registrar liveness-probe
노드 데몬셋에는 세 가지 컨테이너가 위치하고 있는데, 재밌게도 liveness probe 용 컨테이너가 따로 있다.
k get csinodes.storage.k8s.io ip-192-168-2-230.ap-northeast-2.compute.internal -o yaml
관련된 CRD를 확인해볼 수 있는데, 여기에 초반에 설정한 세부스펙이 나온다.
설정으로 할당할 수 있는 드라이버의 개수를 31개로 늘린 것이 여기에서 확인된다.
k get deployments.apps ebs-csi-controller -o jsonpath='{.spec.template.spec.containers[*].name}'
# ebs-plugin csi-provisioner csi-attacher csi-snapshotter csi-resizer liveness-probe
디플로이먼트에는 6개의 컨테이너가 돌아가고 있다.
이것들은 CSI 인터페이스 스펙에 따르는 컨테이너들이다.
k get sc ebs-csi-default-sc -o yaml | yh
처음에 기본 스토리지가 만들어지도록 설정을 했으므로 이미 스토리지 클래스가 만들어져 있다.
테스트
kubestr fio -f read.fio -s ebs-csi-default-sc --size 10G --nodeselector node.kubernetes.io/instance-type=t3.medium
kubestr fio -f write.fio -s ebs-csi-default-sc --size 10G --nodeselector node.kubernetes.io/instance-type=t3.medium
간단하게 똑같이 테스트를 해볼 수는 있는데, 어차피 기본으로 세팅되는 것은 현재 인스턴스에서 사용하는 gp3로 똑같기 때문에 성능 상의 차이는 발생하지 않는다.
read 테스트에서 iops는 3000, bw 12000
write에서 iops 3000, bw 12000.
gp3를 기본 세팅했을 때 설정된 값으로서 기본 ec2의 ami가 설치된 ebs와 당연히 결과는 같다.
테스트가 이뤄지고 있는 사이 콘솔에서 확인해보면 pvc를 위한 볼륨이 하나 만들어진 것을 확인할 수 있다.
ebs 드라이버는 복수의 노드에서 마운팅을 할 수 있도록 하는 ReadWriteMany 옵션을 지원하지 않아서 해당 옵션을 사용하면 에러가 난다.
애초에 ebs 자체가 multi-attach 기능을 활성화하지 않는 이상 블록 스토리지로서 다중 마운팅을 지원하지 않기도 하고, 또한 기본 사용 방향성이 AZ간 교차가 불가능하도록 설계됐기 때문이다.
볼륨 확장
이제부터 ebs 드라이버를 활용해 각종 쿠버네티스에서 활용할 수 있는 스토리지 옵션과 기능을 보기로 한다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-claim
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
storageClassName: ebs-csi-default-sc
---
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
terminationGracePeriodSeconds: 3
containers:
- name: app
image: centos
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: ebs-claim
볼륨 확장을 테스트하기 위한 파드와 pvc를 만들어보자.
현재 이 친구는 1기비바이트의 용량을 가지고 있다.
여기에서 바로 pvc에 대해 k edit등의 방법으로 크기를 확장시킬 수 있다.
나는 2기비바이트로 늘려봤는데, 시간은 조금 걸리는 게 보인다.
콘솔에서는 업데이트가 느리나, 클러스터에서 추적하기로는 2분 정도의 시간이 소요된 것으로 보인다.
확장되는 속도의 차이의 이유는 잘 모르겠지만, 다른 양식으로 테스트할 때는 또 엄청 빠르게 됐다.
참고로 볼륨 확장은 돼도 축소는 되지 않는다.
설계 의도의 관점에서는 볼륨 확장은 필요한 용량을 안전하게 추가 확보하기 위해 마련된 기능이지 자유자재로 볼륨 크기를 조절하라고 내준 기능이 아니기 때문이다.
용량 확보를 위해 새로운 pvc, 새로운 자원을 만들어야 한다면 기존의 데이터를 유지하는데 난항이 생기기에 만들어진 기능일 뿐이다.
볼륨 축소 테스트 실패
하지만, 축소가 가능한 경우가 있기는 한데..
Kubernetes v1.32 - Penelope 기준으로 베타가 된 기능으로, 볼륨 확장 실패에 대해서 축소하는 방향을 리사이징을 하는 것이 기본값으로 설정됐다.
이것도 테스트해보려 했으나, 미리 결론을 말하자면 실패했다.
생각해보니 내가 사용하는 버전이 1.31이었기 때문..
20테라 바이트를 넣어주니 리사이저가 제대로 동작하지 못한다.
이때 볼륨을 축소하면, 1.31에서는 해당 기능이 활성화가 안 돼 있기에 실패한다.
혹시나 하고 해당 노드에 들어가서 kubelet 설정을 건드려봤으나 바뀌는 건 없었다.
애초에 validation에서 막히고 있다는 것은, api 서버쪽에서도 피쳐 게이트를 명시적으로 설정을 해줘야 한다는 것으로 해석할 수 있고, api 서버는 사용자가 건드릴 수 있는 영역이 아니므로 처음부터 클러스터를 구축할 때 버전을 잘 세팅하는 수밖에 없을 것 같다.
스냅샷 구축 및 테스트
간단한 스테이트풀 어플리케이션 구축
볼륨 스냅샷 기능까지 써보기 위해, 기본적인 예제를 만들어보자.
기본 예제는 여기에서 전부 받아서 실행한다.[3]
kubectl label namespace default elbv2.k8s.aws/pod-readiness-gate-inject=enabled
여기에 나는 커스텀 세팅을 조금 더 했다.
ALB Controller를 쓰므로 레디네스 게이트 설정을 해준다.
apiVersion: v1
kind: Service
metadata:
name: wordpress
labels:
app: wordpress
annotations:
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
spec:
ports:
- port: 80
selector:
app: wordpress
tier: frontend
type: LoadBalancer
명확하게 어노테이션도 미리 달아서 내가 원하는 로드밸런서가 만들어지게 했다.
k apply -k .
디렉토리를 하나 파고, kustomize를 이용해 전체 파일을 한번에 빌드한다.
참고로 말하자면, 이 예시에서는 디플로이먼트를 사용하나 replica가 1이다.
현재 활용하는 ebs 드라이버는 한 노드에서만 마운팅하도록 제한하므로, 만약 여러 노드에 걸쳐 파드가 분산되면 먼저 만들어진 파드만 배치가 될 것이다.
테스트를 위해 Topology Spread Constraints로 파드를 분산시켰는데 다른 노드에 볼륨이 없어 스케줄이 될 수 없다고 표시되고 있다.
근데 사실 해당 예제는 같은 노드에 전부 스케줄링을 한다고 해도 디비 락 때문에 두번째 파드부터는 제대로 동작하지 않는다.
그래서 레플리카는 무조건 1로 쓸 수밖에 없는 예제이다..
아무튼 레디네스 게이트가 활성화됐으니, 실제 로드밸런서가 제대로 만들어지고 그쪽에서도 파드로의 헬스체크가 제대로 완료됐다는 것을 알 수 있다.
성공적으로 내 로컬환경에서도 서비스가 접근된다.
딸깍 글을 만들었다.
k exec -ti wordpress-mysql-bbb4fcd55-86wfk -- /bin/bash
mysql -u wordpress -p1234 wordpress
show tables;
describe wp_posts;
select id, post_author, post_name, post_status from wp_posts;
각 명령을 차례차례 실행하여 실제 데이터가 어떻게 담겼는지 확인해본다.
유저 정보는 처음 mysql을 배포할 때 환경변수로 설정된 값이니 양식을 참고하면 된다.
한글이 깨져 나와서 test란 이름으로 글 하나를 더 만들었다.
동적 스냅샷 생성
이제 이 데이터가 제대로 보전될 수 있는지 확인해보자.
kubectl kustomize https://github.com/kubernetes-csi/external-snapshotter/client/config/crd | kubectl create -f -
스냅샷 crd는 해당 레포에서 다운받을 수 있다.[4]
crd들이 성공적으로 설치됐고, 다음으로는 이 crd를 활용할 수 있도록 하는 컨트롤러를 설치한다.
kubectl kustomize https://github.com/kubernetes-csi/external-snapshotter/deploy/kubernetes/snapshot-controller | kubectl create -f -
이제부터 해당 오브젝트들을 사용할 수 있다.
이미 나는 스냅샷을 지원하는 ebs 드라이버를 가지고 있으므로 바로 사용이 가능하다.
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/snapshot/manifests/classes/snapshotclass.yaml
ebs드라이버의 예제 스냅샷클래스를 받아왔다.
이제 본격적으로 스냅샷을 뜨고, 이걸 이용해서 복원을 진행해보자.
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: mysql-snapshot
spec:
volumeSnapshotClassName: csi-aws-vsc
source:
persistentVolumeClaimName: mysql-pv-claim
현재 pvc를 스냅샷으로 만드려고 하니 1분도 안 돼서 스냅샷이 사용 가능한 상태가 됐다.
스냅샷의 id와 스냅샷에 해당하는 볼륨의 정보가 나와있다.
이 값은 콘솔에 나오는 값과 정확하게 일치한다.
정적 스냅샷 컨텐트 생성
스냅샷을 통한 데이터 복구는 이미 볼륨스냅샷을 뜬 상태이기 때문에 가능하지만, 간단하게 정적 스냅샷을 만드는 방법도 보자.
이건 이미 aws에 존재하는 볼륨을 대상으로 해야 하며, 위에서 동적으로 만든 스냅샷을 이용할 것이다.
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
name: static-volumesnapshot-content
spec:
deletionPolicy: Delete
driver: ebs.csi.aws.com
source:
snapshotHandle: {aws에 있는 snapshot id}
sourceVolumeMode: Filesystem
volumeSnapshotClassName: csi-aws-vsc
volumeSnapshotRef:
name: recovered-snapshot
namespace: default
콘솔에서 확인한 스냅샷 id를 이용해서 source 부분을 작성한다.
생각하지 못한 지점은, volumeSnapshotRef를 반드시 지정해야 한다는 것이다.
나중에 만들고자 하는 스냅샷의 이름을 미리 지정해주었다.
크기에 대한 정보가 제대로 가져와진 것으로 보아, 정상적으로 스냅샷 정보를 읽은 듯하다.
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: recovered-snapshot
spec:
source:
volumeSnapshotContentName: static-volumesnapshot-content
그대로 스냅샷도 만들어주었다.
get으로 조회를 해보면, 표기되는 값이 조금은 다르다는 것을 알 수 있다.
그러나 결국 복원 사이즈가 20Gi로서 둘다 잘 세팅됐다는 것을 알 수 있다.
기존 앱 삭제 후 데이터 복원
k delete -k .
이제 남은 pvc가 없는 상태로, 우리 어플리케이션은 미국 갔다..
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
dataSourceRef:
name: recovered-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
kustomize 파일에서 mysql pvc를 하던 부분의 코드를 수정하던 부분을 수정해줬다.
dataSourceRef, dataSource 필드를 이용하면 스냅샷에서 바로 pvc를 생성할 수 있다.
다시 볼륨 크기를 맞추고 실행하자 제대로 이전 데이터가 남은 채로 어플리케이션이 실행됐다.
제대로 데이터가 복원이 됐다는 뜻이다!
스냅샷을 활용한 멀티 az 마운팅
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: dup-binding
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
dataSourceRef:
name: mysql-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
이건 그냥 마지막으로 해본 실험이다.
어차피 한 스냅샷에 대해서 여러 개의 볼륨을 만들어내는 게 가능하다면, 이를 통해 여러 노드에서 한 스냅샷을 활용할 수 있지 않을까?
결론적으로, 가능하다.
스냅샷도 하나의 볼륨이지만, 최소한 aws에서는 스냅샷은 리전 단위로 관리한다.
(즉 여러 가용영역에 생성해줌)
그렇기 때문에 여러 가용 영역에서 해당 스냅샷을 이용해 볼륨을 만들어내는 것이 가능하고, 결과적으로 한 볼륨을 여러 az에서 사용할 수 있게 된다.
물론 파일시스템 스토리지처럼 실시간 동기화를 하는 것은 불가능하겠지만, 같은 데이터를 여러 az에서 보는 것만이 목적이라면 이런 방법도 있다 정도로 생각하면 좋을 듯하다.
결론
간단하게 성능 측정을 하는 도구를 알아본 후, EBS 드라이버를 활용한 각종 쿠버네티스의 스토리지 기능들을 알아보았다.
스냅샷의 경우 직접 만드는 것보다는 시간에 맞춰서 주기적으로 일어나도록 하는 것이 일반적인 사용례일 것이다.
이를 위해서는 KEDA와 같은 이벤트 기반 잡을 실행해주는 도구나, 이런 스케줄러[5]를 사용하면 도움이 될 것이다.
이전 글, 다음 글
다른 글 보기
| 이름 | index | noteType | created |
|---|---|---|---|
| 1W - EKS 설치 및 액세스 엔드포인트 변경 실습 | 1 | published | 2025-02-03 |
| 2W - 테라폼으로 환경 구성 및 VPC 연결 | 2 | published | 2025-02-11 |
| 2W - EKS VPC CNI 분석 | 3 | published | 2025-02-11 |
| 2W - ALB Controller, External DNS | 4 | published | 2025-02-15 |
| 3W - kubestr과 EBS CSI 드라이버 | 5 | published | 2025-02-21 |
| 3W - EFS 드라이버, 인스턴스 스토어 활용 | 6 | published | 2025-02-22 |
| 4W - 번외 AL2023 노드 초기화 커스텀 | 7 | published | 2025-02-25 |
| 4W - EKS 모니터링과 관측 가능성 | 8 | published | 2025-02-28 |
| 4W - 프로메테우스 스택을 통한 EKS 모니터링 | 9 | published | 2025-02-28 |
| 5W - HPA, KEDA를 활용한 파드 오토스케일링 | 10 | published | 2025-03-07 |
| 5W - Karpenter를 활용한 클러스터 오토스케일링 | 11 | published | 2025-03-07 |
| 6W - PKI 구조, CSR 리소스를 통한 api 서버 조회 | 12 | published | 2025-03-15 |
| 6W - api 구조와 보안 1 - 인증 | 13 | published | 2025-03-15 |
| 6W - api 보안 2 - 인가, 어드미션 제어 | 14 | published | 2025-03-16 |
| 6W - EKS 파드에서 AWS 리소스 접근 제어 | 15 | published | 2025-03-16 |
| 6W - EKS api 서버 접근 보안 | 16 | published | 2025-03-16 |
| 7W - 쿠버네티스의 스케줄링, 커스텀 스케줄러 설정 | 17 | published | 2025-03-22 |
| 7W - EKS Fargate | 18 | published | 2025-03-22 |
| 7W - EKS Automode | 19 | published | 2025-03-22 |
| 8W - 아르고 워크플로우 | 20 | published | 2025-03-30 |
| 8W - 아르고 롤아웃 | 21 | published | 2025-03-30 |
| 8W - 아르고 CD | 22 | published | 2025-03-30 |
| 8W - CICD | 23 | published | 2025-03-30 |
| 9W - EKS 업그레이드 | 24 | published | 2025-04-02 |
| 10W - Vault를 활용한 CICD 보안 | 25 | published | 2025-04-16 |
| 11W - EKS에서 FSx, Inferentia 활용하기 | 26 | published | 2025-04-18 |
| 11주차 - EKS에서 FSx, Inferentia 활용하기 | 26 | published | 2025-05-11 |
| 12W - VPC Lattice 기반 gateway api | 27 | published | 2025-04-27 |
관련 문서
| 이름 | noteType | created |
|---|---|---|
| StatefulSet | knowledge | 2024-12-26 |
| 스토리지 | knowledge | 2025-01-10 |
| PersistentVolume | knowledge | 2025-01-11 |
| StorageClass | knowledge | 2025-01-12 |
| AWS EBS CSI Driver | knowledge | 2025-02-18 |
| kubestr | knowledge | 2025-02-19 |
| AWS EFS CSI Driver | knowledge | 2025-02-20 |
| 볼륨 스냅샷 | knowledge | 2025-02-20 |
| E-NFS 볼륨, 스토리지 클래스 설정 | topic/explain | 2024-10-17 |
| E-바인딩과 하드 링크의 차이 | topic/explain | 2025-01-16 |
| E-emptyDir 제한 | topic/explain | 2025-01-16 |
| E-파드 마운팅 recursiveReadOnly | topic/explain | 2025-02-27 |
| E-projected 볼륨 - 동적 업데이트, 중복 활용 | topic/explain | 2025-03-10 |
| T-vagrant 쿠버 버전 업그레이드 | topic/temp | 2025-01-14 |
| T-볼륨 마운팅 위에 마운팅하기 | topic/temp | 2025-01-16 |
| T-마운트 전파 Bidirectioal | topic/temp | 2025-02-28 |