[Kubernetes] PVC로 마음대로 떼었다 붙이는 AWS EBS

 

퍼블릭 클라우드 환경에서 쿠버네티스를 운영할 때 온프로미스보다 편한 점 중 하나가 바로 볼륨 관리 라고 생각합니다.

EBS CSI Driver 를 설치 후 Storage Class, PV 그리고 PVC 를 통해 쉽게 AWS EBS 를 통해 볼륨을 언제 어디서든 가져다 쓸 수 있죠.

아이언맨 슈트처럼?

 

한편, 쿠버네티스에선 다양한 방법으로 볼륨을 사용할 수 있는데요.

컨테이너간 공유를 가능케 해주는 EmptyDir, 노드의 볼륨을 통해 파드간 공유를 가능케 해주는 HostPath, NFS 서버를 사용하는 NFS 기능 등이 있습니다.

 

그라파나를 노드에 배포할 때, 그라파나의 설정 파일은 그라파나가 배포된 노드의 볼륨에 저장이 됩니다. 따라서 만약 그라파나 파드가 다른 노드에 배포가 될 경우 이전에 가지고 있던 그라파나 설정을 불러 올 수 없습니다. 노드의 볼륨이 바꼈기 때문이죠.

 

같지 않은 노드에 파드가 배포될 경우 이전 데이터를 가져올 수 없음

 

AWS EBS 는 보통 한 노드에만 마운트가 가능하기 때문에 쿠버네티스에서 데이터를 저장할 경우 쉽게 마주할 수 있는 문제입니다. 

 

이를 해결하기 위해선 2가지 방법이 있습니다. AWS EFS 를 이용하는 방법과 CNCF 프로젝트인 openEBS 를 이용하는 것이죠.

EFS 를 사용한다면 사실 아주 쉽게 해결할 수 있습니다. 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv
spec:
  capacity:
    storage: 10Ei
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: <EFS ID>::<ACCESSPOINT ID>
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1Ei

 

위 처럼 배포한 후 가져다 사용하기만 하면 됩니다. 

 

그리고 openEBS 를 사용한다면 cStor, Maya, Jiva 등 을 사용할 수 있습니다.

CAS 를 이용해서 노드간 볼륨들을 동기화 시켜주는 방식이죠. 더 자세한 건 여기를 참고해주세요.

openEBS Overview

 

하지만 위 방법들을 사용하지 않는다면 어떻게 해야할까요?

 

한 노드에만 파드가 배포될 수 있도록 nodeSelector 를 지정해주고, 해당 노드에 EBS 를 attach 해주면 됩니다.

 

그라파나와 같은 애플리케이션은 사실 여러 개 필요없이 1개의 파드만 동작 중이면 되기 때문에 여러 노드에 거쳐 배포될 필욘 없습니다.

따라서 노드 하나를 정한 후 거기에 새로운 EBS 를 attach 해주면 됩니다.

 

그럼 한번 해보죠.

 

AWS EBS 에서 볼륨을 생성해두었습니다. 

Dynamic 이 아닌 Static 하게 관리할 것이기 때문에 StorageClass 로 생성할 필요는 없죠.

 

이제 PV 와 PVC 를 생성하죠.

awsElasticBlockStore 는 deprecated 되었기 때문에 Static PV 를 생성하려면 아래와 같이 해야 합니다.
deprecated 관련 문서는 여기 참조

apiVersion: v1
kind: PersistentVolume
metadata:
  name: grafana
spec:
  capacity:
    storage: 8Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""
  csi:
    driver: ebs.csi.aws.com
    volumeHandle: vol-xxxx
    volumeAttributes:
      fsType: ext4
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: ""

 

이후 kubectl get pv 와 kubectl get pvc 를 통해 잘 생성되었는지 확인해줍시다. STATUS 가 Binding 이여야 성공적으로 생성한 겁니다.

 

PV 가 정상적으로 생성되면 Available 이고, PV 가 PVC 와 관계를 맺게되면 Bound 로 바뀌게 됩니다.

여기서 주의할 점은 PV 와 AWS EBS 가 맺어졌다고 해서 STATUS 가 Bound 되는 것은 아닙니다.

그리고 persistentVolumeReclaimPolicy 은 반드시 Retain 으로 해줍니다. Delete 로 하게 되면 UnBound 가 되었을 경우 삭제됩니다.

NAME      CAPACITY  ACCESS MODES   RECLAIM POLICY   STATUS
grafana   8Gi       RWO            Retain           Available
grafana   8Gi       RWO            Retain           Bound

 

이후 deploy.yaml 에 가져다 사용하면 됩니다. AWS EBS 에 따로 저장하고 있으니 추후 그라파나를 다른 노드에 배포한다고 해도 이전 데이터를 충분히 가져다 사용할 수 있습니다.

 

Node A 에서 사용했던 extra new EBS 를 떼어 다시 Node B 에 attach

EBS 같은 경우 워커 노드와 같은 가용 영역에 존재해야합니다. 만약 다른 영역에 있는 워커 노드에 마운트하고 싶다면, 스냅샷을 이용해 원하는 가용영역에 복사 후 사용하셔야 합니다,

 

 

사실 EFS 를 가져다 쓰는게 가장 편합니다. 하지만 다음과 같은 단점이 있죠.

• EFS 는 비용이 비싸다
• EBS 보다 속도가 느릴 수 밖에 없다

 

하지만 관련 글들을 찾아보니 대부분 다른 노드에 파드가 배포되는 경우 설정 파일들을 동기화 시키기 위해선 EFS 를 많이 권장하더라고요. 

이론적으론 EFS 또한 NFS 이기 때문에 EBS 보다 당연히 속도가 느릴 수 밖에 없고, File System 이라는 목적에는 약간 벗어나기는 하지만 EFS 도 충분히 속도면에선 빠르다고 합니다.

 

그럼 오늘은 여기까지!