DevYGwan
AWS EBS CSI Driver을 통한 디스크 동적 프로비져닝 적용 본문
온프렘 서버 환경에서 k8s을 운영할 때는 pod 별로 디스크를 동적으로 관리하기 위해 OpenEBS LVM을 사용했습니다. 그래서 pod을 만들 때 매번 pv & pvc를 만들고 관리해야 되는 불편함을 해소했습니다. 따라서 이번에 AWS에서 k8s을 운영할 때도 이런식으로 운영하면 좋을 것 같아 찾아보던 중, AWS는 EBS(Elastic Block Store)를 CSI Driver를 통해 직접 제어하는 방식도 존재한다는 것을 알게 되었습니다. 따라서 이 2개의 방식을 비교해 최종적으로 AWS CSI Driver 방식을 사용하기로 결정했습니다. 그래서 이번기회에 2가지 방식을 비교하고 왜 이 방식을 사용했는지 정리하려고 합니다.
온프렘 관리 방식 vs AWS 관리 방식
| 구분 | 온프렘 (OpenEBS LVM) | AWS (EBS CSI Driver) |
| 프로비져닝 | LVM VG/LV 직접 관리 | EBS 볼륨 자동 생성/삭제 |
| 드라이버 | OpenEBS | aws-ebs-csi-driver |
| IAM 권한 | 불필요 | IAM User 또는 인스턴스 프로파일 필요 |
| 멀티 AZ | 불가 | AZ 종속 (EFS로 대체 가능) |
| 볼륨 확장 | 수동 | allowVolumeExpansion: true로 자동 |
EBS CSI Driver 사용 이유
- 기술적으로는 AWS 에서도 OpenEBS를 사용할 수 있지만, 아래와 같은 이유로 AWS EBS CSI Driver를 사용하기로 결정했습니다.
OpenEBS LVM은 로컬 디스크를 소프트웨어로 추상화 하는 도구입니다.
온프렘에서 도입한 이유는, 실제 물리 디스크가 노드에 붙어있고 이를 k8s가 바로 알 수 없는 상황이기 때문에 OpenEBS라는 중간의 연결고리로 자동 관리할 수 있도록 진행한 것입니다. 하지만, AWS의 경우 그 역할 자체를 EBS 자체가 해버립니다.
온프렘: 물리디스크 → OpenEBS(추상화) → k8s PVC
AWS: EBS → CSI Driver(연결) → k8s PVC
비교
| OpenEBS on AWS | EBS CSI Driver | |
| 디스크 관리 주체 | OpenEBS Operator | AWS 인프라 |
| 볼륨 생성 위치 | EC2 인스턴스 로컬 | AWS 독립 EBS 서비스 |
| 노드 죽으면 | 데이터 위험 | EBS는 노드와 분리되어 안전 |
| 스냅샷/백업 | 별도 구성 필요 | AWS 스냅샷 네이티브 지원 |
| 모니터링 | 별도 구성 | CloudWatch 자동 연동 |
| 운영 오버헤드 | OpenEBS 버전관리, 장애대응 | AWS가 관리 |
| 비용 | EC2 스토리지 + OpenEBS 오버헤드 | EBS 비용만 |
따라서 AWS에서 OpenEBS를 사용하는 것은 이미 제공되는 기능을 다시 구현함과 동시에, 더욱 더 관리 포인트만 늘어나는 것이기 때문에 굳이 AWS에서는 OpenEBS를 사용하는 것보다 기본적으로 제공되는 EBS CSI Driver를 사용하는 것이 좋습니다. (Naver Cloud에서도 EBS CSI Driver를 사용하려고 했었는데, 그때는 관리형 k8s(nks)를 사용하지 않으면, csi driver를 기본적으로 사용할 수 없어서 그때는 OpenEBS를 사용했습니다.)
그렇다면, 지금부터 어떻게 AWS EBS CSI Driver을 사용할 수 있는지 정리해보도록 하겠습니다.
정리하기에 앞서, 이게 어떻게 동작하는지를 간략하게 설명드리도록 하겠습니다.
AWS EBS CSI Driver 동작 방식
- 기본적으로 EBS CSI Driver의 동작은 2개의 컴포넌트를 통해 동작합니다.
- ebs-csi-controller : 볼륨 생성/삭제를 담당
- ebs-csi-node : 각 노드에서 실제 마운트를 담당
- 동작 순서
- 1~2. PVC 생성 → Pending — kubectl apply로 PVC를 만들면 k8s API Server가 받아서 Pending 상태로 등록
- 3. controller가 감지 — ebs-csi-controller 안의 external-provisioner 사이드카가 Pending PVC를 watch하다가 ebs.csi.aws.com provisioner인 걸 확인하고 처리 시작
- 4~5. AWS API 호출 → EBS 볼륨 생성 — IAM 권한으로 ec2:CreateVolume 호출. WaitForFirstConsumer 덕분에 Pod가 스케줄된 AZ에 맞춰 볼륨이 생성됨
- 6. PV 자동 생성 → Bound — controller가 생성된 EBS 볼륨으로 PV를 만들고 PVC와 바인딩. 상태가 Bound로 변경
- 7. ebs-csi-node가 attach — 해당 노드의 ebs-csi-node DaemonSet이 ec2:AttachVolume으로 볼륨을 노드에 붙임
- 8. Pod 마운트 — 노드에 attach된 볼륨을 Pod의 지정 경로(/data 등)에 마운트. Pod가 Running 상태가 됨
PVC 생성 요청이 들어오면 EBS CSI Driver가 AWS API를 호출하여 EBS 볼륨을 자동 생성하고 해당 Pod에 마운트한다.
PVC 생성 요청
→ EBS CSI Driver (kube-system)
→ AWS API 호출 (ec2:CreateVolume, ec2:AttachVolume ...)
→ EBS 볼륨 생성 및 Pod 마운트
Talos는 Self-managed 클러스터이므로 EKS 애드온 방식을 사용할 수 없기 때문에 Helm으로 직접 설치한다.
IAM 생성
- 위와 같이 EBS CSI Driver가 AWS API를 호출하려면 IAM 권한이 필요합니다. 따라서 필요한 권한을 가진 IAM User를 생성하고 Access Key를 k8s Secret으로 CSI Driver에 주입하는 방식을 통해 이를 관리합니다.
- AmazonEBSCSIDriverPolicy 권한을 가진 유저를 생성하고 AccessKey와 SecretKey을 생성해 Secret으로 등록합니다.
AmazonEBSCSIDriverPolicy 권한
- "EBS 볼륨의 생명주기 전체를 관리하는 권한"
- EBS의 생성 → attach → detach → 삭제까지. 단, 삭제는 CSI가 직접 만든 볼륨만 가능하도록 태그 조건으로 범위가 제한됨
Secret 생성
- 위에서 생성한 aws key를 k8s에서 안전하게 사용하기 위해 k8s에 secret으로 등록합니다.
# aws ebs csi driver secret
apiVersion: v1
kind: Secret
metadata:
name: aws-secret
namespace: kube-system
type: Opaque
stringData:
AWS_ACCESS_KEY_ID: <AWS ACCESS KEY 값>
AWS_SECRET_ACCESS_KEY: <AWS SECRET KEY 값>
EBS CSI Driver 설치 (Helm)
- EBS CSI Driver을 설치를 helm을 통해 진행합니다.
- helm으로 사용할 설정 파일 생성 후, 이를 적용하여 설치를 진행합니다.
helm 설정 values.yaml 파일 생성
controller:
volumeModificationFeature:
enabled: true
extraVolumeTags:
managed-by: <태그 값>
replicaCount: 1
envFrom:
- secretRef:
name: <secret 명>
node:
envFrom:
- secretRef:
name: <secret 명>| 옵션 | 설명 |
| volumeModificationFeature.enabled | iops, throughput 등 볼륨 스펙을 나중에 변경 가능하게 함 |
| extraVolumeTags | 생성되는 EBS 볼륨에 AWS 태그 추가 (관리/비용 추적용) |
| envFrom.secretRef | 위에서 생성한 aws-secret을 환경변수로 통째 주입 (AWS_ACCESS_KEY_ID 등) |
EBS CSI Driver 설치 (Helm)
# helm repo 생성
helm repo add aws-ebs-csi-driver https://kubernetes-sigs.github.io/aws-ebs-csi-driver
helm repo update
# aws ebs csi driver 설치
helm install aws-ebs-csi-driver aws-ebs-csi-driver/aws-ebs-csi-driver \
--namespace kube-system \
--values tmp-pod-ebs-csi-values.yaml
이렇게 하면, 기본적으로 위에서 말씀드린
-> ebs-csi-controller
-> ebs-csi-node
이 두개가 노드마다 각각 생성됩니다.
그렇다면, 기본적인 준비는 끝났고 이를 통해 어떻게 파드에 적용해 사용할 수 있는지를 설명드리도록 하겠습니다.
StorageClass 생성
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: <storageClass 명>
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
parameters:
type: gp3
iops: "3000"
throughput: "125"
encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true| 옵션 | |
| is-default-class | PVC에 storageClassName을 명시하지 않으면 이 StorageClass가 자동으로 사용되게끔 설정 |
| provisioner | 이 StorageClass로 PVC가 생성되면 어떤 드라이버가 처리할지 지정 |
| type | EBS 볼륨 타입 |
| iops | 초당 I/O 처리 횟수 |
| throughput | 초당 데이터 전송량(MiB/s) |
| encrypted | EBS 볼륨 암호화 활성화 |
| WaitForFirstConsumer | PVC가 생성되는 시점이 아니라 Pod가 스케줄된 시점에 볼륨을 생성. |
| reclaimPolicy | PVC가 삭제됐을 때 EBS 볼륨 처리 방식 설정 |
| allowVolumeExpansion | PVC의 storage 용량을 늘리는 게 가능. 운영 중 용량 부족 시 다운타임 없이 확장 가능. (축소 불가) |
이렇게 만든 storageClass를 pod 생성시 storageClass 선언으로 해서 사용
결과
- pod를 띄울 때 storageClass 적용 후 Pod 생성 시 pv & pvc 생성 후 그거와 연결된 AWS EBS가 자동으로 생성되는 것을 확인
주의 사항
- AZ 종속성 — EBS는 AZ 종속이다. 노드가 다른 AZ로 옮겨가면 볼륨 재마운트가 안 된다. 멀티 AZ 공유가 필요하면 EFS를 사용해야 한다.
- WaitForFirstConsumer — WaitForFirstConsumer를 반드시 설정해야 한다. 미설정 시 PVC 생성 시점에 AZ가 랜덤으로 선택되어 Pod와 볼륨이 다른 AZ에 생길 수 있다.
- 비용 관리 — reclaimPolicy: Retain 설정 시 PVC 삭제해도 EBS 볼륨은 보존된다. 불필요한 비용 발생에 주의하고 주기적으로 미사용 볼륨을 정리해야 한다.
- 접근 모드 — EBS는 ReadWriteOnce만 지원한다. 여러 Pod에서 동시에 마운트해야 한다면 EFS(ReadWriteMany)를 사용해야 한다.
정리
이렇게해서 AWS에서 k8s을 운영할 때, 효율적인 디스크 관리에 대해서 정리 및 적용해봤습니다. 여러 고객사에 니즈를 맞추기 위해 Onprem & AWS & NCP에서 서버를 운영하다보니, 최대한 하나로 맞추기 위해 노력하지만 플랫폼 특성상 다른 부분이 존재해 매번 새롭게 서버 세팅을 하게 되는 것 같습니다...