EKS Storage & NodeGroup
본문
파드의 내부 데이터는 기본적으로 파드가 종료되면 그걸로 끝 ! 전부 삭제되어 버림 똑같은 파드를 재시작해도 데이터는 연동되지 않음
파드는 Stateless 애플리케이션이다
그래서 파드가 죽어도 작업했던 데이터를 보존하기 위해서 나온 것이 PV( Persistent Volume )
해당 PV는 Stateful 애플리케이션으로 상태를 보존한다.
PV는 어느 노드에서도 연결해서 사용 가능 Ex) NFS , Aws EBS
그리고 PV를 파드가 생성될 때 자동으로 마운트해주는 기능을 동적 프로비저닝 이라고 한다.
기본 컨테이너에서 아무런 설정을 하지 않으면 임시 파일 시스템을 사용하기 때문에 파드가 종료되면 기존 데이터가 다 삭제가 되어진다.
busybox 파드를 만들고 해당 파드에 다음과 같은 글을 입력한 다음 파드를 삭제
파드를 삭제후 다시 똑같은 busybox 파드를 생성하면 기존에 작업했던 데이터가 날라가고 보이지 않음 -> stateless
호스트 Path
다음과 같이 호스트 Path를 사용하는 스토리지 클래스를 생성후 PVC를 생성
아래와 같은 파드를 생성
파드의 컨테이너의 볼륨 마운트를 persistent-storage로 하고 해당 볼륨은 PVC는 localpath-claim을 가리킨다
해당 파드의 데이터를 확인해보자
해당 파드의 데이터를 노드1에서도 확인할 수 있다.
해당 파드를 삭제후 다시 확인해도 PVC를 마운트하기 때문에 이전의 데이터가 남아있음을 확인할 수 있다.
디스크 I/O 성능 확인
- 디스크 성능을 확인 해보면 r/s 3000으로 이는 EBS볼륨의 IOPS랑 동일함
처리 결과
AWS EBS Controller
EBS 볼륨을 만들고 해당 볼륨을 파드가 부착해서 사용
워커노드의 디스크 용량 관리 필요없이 볼륨 만들어서 바로 똭 붙이면 되니까 간편!
다만 같은 가용 영역 안에 있어야 한다.
gp3 스토리지 클래스를 생성하고 확인
PVC를 생성
아래와 같이 설정된 파드를 배포 - 볼륨 마운트를 PVC로 한다. 마운트가 되는 순간 EBS도 생성
또 배포한 파드의 파일 시스템을 확인해보면 4G 용량의 볼륨이 마운트 되어 있음을 확인할 수 있다.
EBS 볼륨을 증가시킬 수 있음 다만 줄일 수는 없다 .
AWS Volume SnapShots Controller
볼륨 스냅샷을 생성
장애를 만들어서 스냅샷의 복원 능력을 확인
일단 강제로 파드와 pvc를 삭제
동적으로 만들어진 볼륨이 삭제됨을 확인
다시 PVC를 만드는데 데이터 소스는 스냅샷으로 설정해서 스냅샷에 저장된 것들을 그대로 복원
스냅샷으로 동일한 볼륨을 만들고 그대로 복원됨
데이터도 그대로 삭제되고 다시 배포된 후로 이어서 기록을 하는 중
AWS EFS Controller
EBS와는 다르게 네트워크 저장소라 가용영역이 달라도 마운트 가능
PVC 생성
파드 볼륨을 PVC로 지정
각 파드마다 마운트 된 파일 시스템을 확인 - 동일한 EFS
배포된 각 앱마다 마운트된 EFS를 사용하여 데이터를 저장
노드 그룹
현재 EKS에서 노드그룹은 ng1 단 하나만 존재
신규로 노드그룹2를 생성을 할 건데 다음과 같은 instance store에서는 인스턴스가 중지 및 종료 혹은 절전 모드로 전환이 될 때 데이터 손실이 있을 수 있으니 주의가 필요하다고 한다.
새롭게 EC2가 만들어졌고 EKS에서 ng2라는 이름으로 노드그룹에 추가가 되어 있음
새롭게 만든 노드 그룹에 테스트를 한 결과 인스턴스 스토어가 기존의 IOPS 3000보다 약 7배 빠른 것을 확인 할 수 있음
ARM계열로 노드그룹 확인
새롭게 노드그룹이 생성됨
파드를 배포하면 새롭게 생성된 노드그룹3에 배치되어 배포가 됨을 확인
Fargate
- 데이터플레인 영역까지 완전히 AWS에게 맡기는 방법
- 퍼블릿 서블릿 내에서는 동작하지 않고 프라이빗 서브넷 내에서만 동작한다.
