개발놀이터

AWS EKS PV로 EBS볼륨 바운드하기 본문

배포/kubernetes

AWS EKS PV로 EBS볼륨 바운드하기

마늘냄새폴폴 2024. 9. 27. 23:50

이전 포스팅에서 어느정도 이어지는 포스팅입니다. 물론 완전히 이어지진 않아서 따로 봐도 상관없습니다. 

 

https://coding-review.tistory.com/555

 

AWS EKS로 스프링 프로젝트 배포하기

이번 포스팅에선 EKS를 이용해서 스프링 프로젝트를 배포해보도록 하겠습니다.  온프레미스로 k8s를 구축할 땐 말도 드럽게 안듣더니 EKS로 하니까 역시 돈이 좋다는 것을 체감하고 있습니다. 개

coding-review.tistory.com

 

이전 포스팅에서 단순하게 MySQL 파드, 서비스 / 스프링 파드, 서비스를 배포해서 외부에서 접속했던 것이라 어느정도 고도화가 필요했습니다. 

 

PV / PVC를 EBS볼륨과 바운드하는 것을 시작으로 Nginx로 웹서버 - WAS 서버 구축하기 등을 천천히 이어나가겠습니다. 

 

이번 포스팅에선 EBS를 PV로 바운드하는 방법에 대해서 정리해보도록 하겠습니다. 

 

PV로 EBS볼륨 바운드

우선 저는 스프링 프로젝트에 PVC를 붙여서 PV와 연결해보도록 하겠습니다. PV는 저장소인만큼 데이터베이스와 잘 어울릴 것 같지만 이전 포스팅에서도 언급했듯이 데이터베이스같은 강한 stateful 애플리케이션은 쿠버네티스와 어울리지 않습니다. 

 

때문에 제 프로젝트를 MSA로 전환하는 과정에서 필요한 발판으로서 스프링 프로젝트와 PV를 연결해보았습니다. 

 

PVC 생성

우선 EKS 클러스터를 구축했다면 StorageClass가 자동으로 생성되어있습니다. 

 

 

이렇게 StorageClass가 만들어져있고 이를 열어보면 다음과 같습니다. 

 

kyoungsuk@imgyeongseog-ui-MacBookPro was % kubectl get sc
NAME   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2    kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  4d3h
kyoungsuk@imgyeongseog-ui-MacBookPro was % kubectl get sc gp2 -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"gp2"},"parameters":{"fsType":"ext4","type":"gp2"},"provisioner":"kubernetes.io/aws-ebs","volumeBindingMode":"WaitForFirstConsumer"}
  creationTimestamp: "2024-09-23T11:03:12Z"
  name: gp2
  resourceVersion: "284"
  uid: 728a001e-d21e-4c81-bc3b-3d0cf9d9c1cc
parameters:
  fsType: ext4
  type: gp2
provisioner: kubernetes.io/aws-ebs
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

 

이렇게 되어있는걸로 봐선 EBS볼륨을 io1이나 io2로 설정해서 만들 수 있는 StorageClass도 만들 수 있을 것 같긴 하군요. 이건 따로 실습해봐야겠습니다. 

 

이제 본격적으로 PVC를 만들어보겠습니다. 

 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: spring-pvc
  namespace: was
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: gp2

 

PVC를 다음과 같이 생성했고 스토리지 용량은 5기가 StorageClassName은 앞서 언급했던 gp2로 설정했습니다. AccessMode에 대해서는 이전 쿠버네티스 이론 : 볼륨 편에서 자세히 다뤘으니 넘어가도록 하겠습니다. 

 

그리고 이 PVC를 배포해주시면 됩니다. 그럼 반은 성공한 것이지요. 

 

kubectl apply -f ./was-pvc.yml

 

그리고 이제 중요한 스프링 프로젝트에 PVC를 붙이는 것인데요. 

 

우선 파드를 만드는 곳에선 PVC를 붙일 수 없다는 것을 먼저 말씀드리고싶네요. 방법이 있을진 모르지만 우선 제가 실습했던 다양한 상황에선 파드를 만드는 파일에선 PVC를 붙일 수 없다는 결론을 냈습니다. 

 

그래서 저는 ReplicaSet을 만들고 그곳에 PVC를 붙였습니다. 

 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: spring-rs
  namespace: was
spec:
  replicas: 2
  selector:
    matchLabels:
      type: was
  template:
    metadata:
      labels:
        type: was
    spec:
      volumes:
      - name: was-storage
        persistentVolumeClaim:
          claimName: spring-pvc
      containers:
      - name: was-container
        image: 192021811870.dkr.ecr.ap-northeast-2.amazonaws.com/k8s/ecr:latest
        volumeMounts:
        - name: was-storage
          mountPath: /was/storage
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
          limits:
            cpu: 500m
            memory: 1Gi
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: deploy
                operator: In
                values:
                - was

 

하나씩 풀어서 해석해보겠습니다. 

 

  • 우선 replicas는 2로 설정했습니다. 사실 노드의 자원 상황을 고려하면 1이 적당하지만 억지로 2개를 띄워서 PV가 제대로 연결되었는지 확인하고 싶어서 2로 설정했습니다. 
  • ReplicaSet에서 어떤 템플릿의 파드를 사용할 것인지를 정의하는 부분에서 PVC를 연결했습니다. name은 volumeMounts에서의 name과 동일하게 맞춰줘야하고 PVC를 만들 때 설정했던 name과 persistentVolumeClaim의 claimName과 같아야합니다. 
  • volumeMounts에선 PV가 연결되었다는 것을 알아보기 쉽게 /was/storage로 설정했습니다. 
  • resources는 replicas를 두개 띄우기 위해서 조금 빡빡하게 설정했습니다. 실제로 스프링 프로젝트를 돌리기 위해서는 CPU 1코어에 2GB 메모리가 적당하긴합니다.
  • 저는 PodAffinity를 사용해서 노드를 선택했지만 nodeSelector로도 충분히 대체가능합니다. 

이제 ReplicaSet을 배포해보면?

 

 

이렇게 배포가 된 것을 볼 수 있습니다. 그리고 pv도 조회를 해보면

 

 

이렇게 잘 만들어진 것을 볼 수 있습니다. Reclaim Policy가 Delete로 되어있는 것은 이 ReplicaSet을 삭제하면, 정확히는 PVC를 삭제하면 PV도 자동으로 삭제하겠다는 의미입니다. 

 

이 내용도 쿠버네티스 이론 : 볼륨 편에서 자세히 다뤘으니 해당 포스팅을 참고해주세요!

 

그리고 EBS볼륨이 실제로 만들어졌는지 확인해보겠습니다. 

 

 

보면 우리가 만든 5GB짜리 볼륨이 생성된 것을 볼 수 있습니다. 

 

그래도 믿을 수 없다! 직접 파드에 exec 명령어로 들어가서 폴더를 확인해보겠습니다. 

 

 

우선 첫번째로 들어간 파드에서 실제로 was폴더가 만들어져있었고 안에 들어가서 lalala 폴더를 하나 만들었습니다. 

 

이제 다른 파드로 들어가서 똑같은 폴더가 만들어졌는지 확인해보겠습니다. 

 

 

다른 파드로 들어가서 직접 lalala폴더를 확인했습니다. 

 

추가적으로 어떤 스토리지가 마운트 되었는지 명령어를 날려서 확인해보면 

 

 

이렇게 /was/storage로 5GB의 볼륨이 마운트된 것을 확인할 수 있습니다. 

 

마치며

이렇게 스프링 프로젝트에 PVC를 연결하고 PV로서 EBS볼륨을 마운트해봤습니다. 실제로 서비스를 개발하다보면 다른 서버에서 동일한 파일을 바라봐야하는 경우가 종종 있는데요. 

 

보통 클라우드로 인프라를 구성했다면 EBS볼륨을 이용해서 이렇게 같은 볼륨을 마운트해 같은 파일을 바라보게 하는 것이 가능합니다. 

 

이것을 EKS 클러스터는 조금 더 쉽게 사용하게 만들어주는 것 같네요. 실제로 EBS볼륨도 자동으로 만들어지고 마운트하는 작업까지 자동으로 되니까 너무 편하네요. 

 

여기까지 포스팅을 마쳐보도록 하겠습니다. 긴 글 읽어주셔서 감사하고 오늘도 즐거운 하루 되세요!