3주차 - EKS Storage & Nodegroup

1. 도입

• AWS 내에서 K8S 를 사용하면서 생기게되는 페인포인트를 지적해주시면서 실습들을 진행했습니다.

• 성능적인 부분을 측정해볼 기회가 적은데 괜찮은 Add-on 들과 프로젝트를 소개받았습니다.

• 전반적으로 k8s의 volume 관련 기능들을 aws에서는 어떻게 (add on)을 이용해서 구현이 되어있는지

• 그와 반대로, aws에서 k8s의 볼륨 관련 기능들을 어떻게 사용하게끔 인터페이스를 노출하고 있는지 알아볼 수 있었습니다.

거두절미하고 빠르게 이번주 내용을 복습해봅시다.

2. 선수 지식

해당 지식들은 선수지식들이라고 가정을 하고 진행할 예정입니다.

Kubernetes

• emptyDir

• hostPath

• PVC/ PV

• Volume Snapshot

AWS

• EFS

• EBS

• Node Group

  • Instance Type

• Fargate

• CSI

3. Amazon EKS 원클릭 배포 환경 가이드

A. 설정

• WEEK 2와 대부분 동일하고 달라진 부분은 Node 별 pod 갯수 설정이었습니다.

4. 스토리지 이해

A. 첫번째문제: 파드의 데이터 휘발됩니다.

출처: AWS

• 파드의 데이터는 파드가 정지되면 모두 삭제가 됩니다.

• Stateless한 애플리케이션인데 Stateful한 데이터를 저장하려면 PV(Persistent Volume) 와 PVC가 필요합니다.

• 위의 그림과 같이 POD는 PVC를 이용해서 PV에 바운드가 되고 PV는 실제 스토리지를 가리키고 있습니다.

• 여기서 AWS의 PV는 Amazon EBS, EFS가 될 수 있습니다. (비용, 접근성, 속도에 따라 사용가능)

• 여기서 중요한 부분은 퍼시스턴스 볼륨을 파드가 생성할 때 자동으로 생성후에연결해주는 부분입니다.

• 해당 기능을 동적 프로비저닝이라고합니다.

B. 두번째 문제: K8S에서 AWS와 다른 라이프사이클을 어떻게 적용할 것인가?

• storage 클래스들은 미리 정의

• 해당 부분들을 감시하고 있다가 Controller를 이용해 할당하는 구조로 보입니다.

• 별도의 controller pod를 통해 AWS API를 사용해서 실제 EBS Volume을 생성하는 역할을 해줍니다.

• Daemon Set node pod은 AWS API를 사용해서 K8s 노드에 ebs volume을 붙여줍니다.

• 중요한점은 `CSI 드라이버의 구조를 통해 AWS 의 EBS가 pod에 할당이 된다` 입니다.

C. [실습] 기본 컨테이너 임시 파일시스템 사용 / 노드의 볼륨 갯수 제한

목적: 노드에게 붙일 수 있는 볼륨 갯수 제한 확인 및 임시 파일 시스템 사용시 파일 정보 변경 확인

실험 설정:

1. 노드에 붙일 수 있는 볼륨 갯수 제한 확인

   1. kubectl describe node | grep Allocatable: -A1

2. 파드 배포

3. 파일 확인

4. 파드 삭제 후에 다시 확인

실험 결과:

• 파드 제거후 데이터 없어진 부분을 확인할 수 있습니다.

D. [실습] hostPath를 사용하는 PV/PVC 배포

목적: 파드에 PV 부착 이후에 파드 제거 시 PV 남아 있는지 확인

실험 설정:

1. Local Path Provisioner 배포

2. PV/PVC 사용 파드 생성

3. 파드 삭제 후에 파드 재생성해서 데이터 확인

실험 결과:

• pvc 생성 확인

• pod 생성 확인

• pv에 affinity 내용도 확인 가능합니다.

• 현재 데이터 확인

• 과거의 데이터도 out.txt 파일이 가지고 있는것을 확인

E. [실습] Kubestr & sar 모니터링 및 성능 측정 확인

목적: Volume의 성능 측정

실험 설정:

1. kubestr 툴 다운로드

2. 3개의 노드에 대해서 모니터링

3. kubestr 툴 사용해서 io 발생시키기

4. 결과값에 대해서 확인

실험 결과:

• kubestr을 통해서 io 발생

kubestr fio -f fio-read.fio -s local-path --size 10G

• node에서의 read 속도 3000정도로 보이는 것을 확인

• 결과값이 3022 IOPS가 나오는 것 확인

5. AWS EBS Controller

A. AWS EBS Controller 동작

출처: https://malwareanalysis.tistory.com/598

• 4.B 섹션에서 언급된 바와 같이 Volume 이 존재하지 않으면 CSI 컨트롤러가 aws api를 이용해 생성하게 됩니다.

B. [실습] Amazon EBS CSI driver as an Amazon EKS add-on

목적: CSI 드라이버를 설치하고 실제 스토리지 클래스를 생성하는것을 확인

실험 설정:

1. aws-ebs-csi-driver 설치 버전 확인

2. ISRA 적용

3. EBS CSI Driver Add on 추가

4. sci-controller 추가 확인

5. gp3 스토리지 클래스 생성

실험 결과:

• ISRA가 ebs_csi_driver를 위해 정책이필요해서 생성했습니다.

• CSI 관련 노드가 올라온것을 확인

• Storageclass 생성

• gp3의 성능 측정시에 3000이 나오게 됐는데 해당 사항은 무엇이 문젠지 확인이 필요합니다.

• min max가 각각 차이가 커서 provisioned 된 iop가 아닐까 추정해봅니다.

C. [실습] PVC/PV 파드 테스트

목적: PVC 와 PV 를 생성했을 때, 추가된 EBS 볼륨 확인

실험 설정:

1. 워커노드에서 파드에 추가한 EBS 볼륨 모니터링

2. PVC 생성

3. 추가된 EBS 볼륨 확인

4. 파드내 추가된 볼륨 정보 확인

5. 볼륨 증가, IOPS 증가도 조정이 가능하다.

실험결과:

• pvc 생성, pv 생성이후 volume이 어떻게 붙어있는지 확인

• 해당 pv를 확인 해보니 NodeAffinity로 select 해서 node에 할당되어 있음

• 자세히 보면 pv 할당 및 정보가 나열되어 있습니다.

• 볼륨 증가 및 IOPS 증가도 가능합니다.

6. AWS Volumes Snapshot Controller

A. 문제:

B. [실습] Volume Snapshot 컨트롤러 생성 및 사용 확인

목적: 데이터 복원 과정을 snapshot으로 재현할 수 있다.

실험 설정:

1. 워커노드에서 파드에 추가한 EBS 볼륨 모니터링

2. PVC 생성

3. 추가된 EBS 볼륨 확인

4. 파드내 추가된 볼륨 정보 확인

5. 볼륨 증가, IOPS 증가도 조정이 가능하다.

실험결과:

• 일단 SNAPSHOT CRD 들을 설치합니다.

• SNAPSHOT CONTROLLER도 설치합니다. (미래에 snapshot 기능에 포함될 예정이라고하네요)

• 파드 생성으로 데이터 생성

• 스냅샷 생성

• 스냅샷이 생성된것을 확인 할 수 있습니다.

• 해당 데이터 살아 있는것 확인

7. AWS EFS Controller

A. 문제

• EBS는 하나의 AZ에 국한되어있지만 EFS를 사용하게되면 네트워크 접속으로 파일 시스템을 공유할 수 있습니다.

https://dev.to/awscommunity-asean/aws-eks-with-efs-csi-driver-and-irsa-using-cdk-dgc

• 다음과 같이 K8S에서 EFS 컨트롤러를 통해서 Storage class를 구성할 수 있습니다.

B. [실습] EFS 파일시스템 확인 및 EFS Controller 설치

목적: EFS 가 컨트롤러를 통해서 정상적으로 탑재되었는지 확인

실험 설정:

1. EFS 정보 확인

2. IAM 정책 생성

3. ISRA 설정

4. ISRA 확인

5. EFS 컨트롤러 설치

실험결과:

• 정책 설정 및 할당 확인

• EFS 설치

• 설치 이후에 EFS 가 탑재되는 것을 확인

8. Mountpoint for Amazon S3 CSI Driver

• 해당 부분은 실습을 진행하지 않았고 좋은 리소스를 찾았다. 관심이 있으신분들은 확인해보시면 될것같다.

• https://velog.io/@euijoo3233/AWS-Elastic-Kubernetes-Service-3-EKS-Storage-AEWS-2%EA%B8%B0#5-mountpoint-for-amazon-s3-csi-driver

9. EKS Persistent Volumes for Instance Store

A. 문제

• 중지 종료일 경우에는 해당 INSTANCE STORE가 날라가게됨

• 하지만 빠름

B. [실습] 인스턴스 스토어및 확인신규 노드 그룹 ng2 생성

목적: 인스턴스 스토어의 볼륨의 스토리지 크기를 보여주기 위함

실험 설정:

1. 인스턴스 스토어 볼륨 C5 스토리지 크기 타입 확인

2. 신규 노드 그룹 생성

3. 디스크 크기 확인

• 해당 실험에서는 노드에 접속하는 부분을 실행하지 못해서 완료하지 못했습니다.

• 트러블 슈팅이 필요합니다.

• 인스턴스 스토어의 IOPS 는 2만대 VS EBS의 IOPS는 3천대로 결과가 예측됩니다.

10. Add Node Group

A. [실습] Graviton (ARM) Instance 노드그룹 생성

목적: ARM 기반의 노드그룹을 생성하기 (ARCHITECTURE가 달라서 전산성이 INTEL 에 비해 우수)

실험 설정:

1. 신규 노드 그룹 생성

2. 노드 생성 확인

3. TAINT 설정

4. POD들을 Graviton 노드에 생성

실험 결과:

• graviton 생성 확인

• taint 를 설정해서 arm과 아키텍쳐가 맞지않는 애플리케이션은 호스팅 되지 않게끔 설정

• Taint 설정 확인

• toleration에 taint와 매칭된 busybox를 실행했을때, 알맞게 해당 노드에서 service 되고 있음 을 확인

느낀점과 배운점

• 점점 기본기에서 Node Group을 생성하는 법을 배우게됨으로써 EKS 관리 자동화를 노려볼 수 있는 기술들을 많이 배웠습니다.

• 전반적인 볼륨에 관한 동작원리와 AWS의 EC2 배포도 K8S을 통해 할 수 있습니다.