AWES[1기](Amzaon EKS Study)

[AWES] 3주차 - EKS Storage & Node 관리

Joon0464 2023. 5. 10. 21:36

 

1. 실습환경 배포

기존과 달라진 점은 "EFS 생성"이 추가된 cloudformation stack을 사용해야한다.
-> https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick2.yaml
 
기타 파라미터 값은 이전 1주차, 2주차와 동일하기 때문에 생략하도록 하겠습니다.
 

기본 설정 및 EFS 확인

 
 
 


context 이름 변경

EFS를 마운트하고 정상적으로 마운트 되었는지(파일 생성 및 삭제 등) 확인합니다.
 

스토리지클래스 및 CSI 노드 확인

 
노드 Private IP 변수 설정 및 보안그룹 설정은 기존 1주차, 2주차와 동일합니다.
 

AWS LB/ExternalDNS, kube-ops-view 설치


AWS LB Controller 설치
route53에 미리 등록한 개인 도메인 주소를 확인합니다.
확인한 도메인 주소를 MyDomain 변수로 설정하고 External DNS를 배포합니다.
ExternalDNS를 배포 후 Route53을 다시 확인하면 다음과 같이 3개의 레코드가 추가됩니다.
마지막으로 kube-ops-veiw도 helm 을 통해 배포해줍니다.

 

2. 쿠버네티스에서의 파드 스토리지

- 쿠버네티스에서 파드가 terminating되면 컨테이너 내부 데이터는 모두 삭제됩니다.(Stateless)
- 따라서 Stateful 한 방식의 파드 스토리지 관리가 필요합니다.(e.g. DB 파드)
 

출처 :  https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/

- 이를 위해 쿠버네티스에서는 PV & PVC를 통해 구현
PV : 관리자가 프로비저닝하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 클러스터 스토리지
- PVC : PVC은 파드에 PV를 할당하기 위한 스토리지에 대한 요청
- 동적 프로비저닝(Dynamic Provisioning) : 파드가 생성될 때 자동으로 볼륨을 마운트하여 파드에 연결하는 기능

출처 : https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/
출처 : https://aws.amazon.com/ko/blogs/tech/persistent-storage-for-kubernetes/

Reclaim Policy


Reclaim Policy는 Kubernetes에서 PV(Persistent Volume) 자원을 삭제할 때 PV와 관련된 스토리지 볼륨의 처리 방법을 의미합니다. 
 

  • Retain(보존)
    • PV에서 볼륨과의 연결을 삭제하더라도 스토리지 자체는 보존
    • 이후 PV 볼륨이 새로운 클레임 요청을 받게되면 기존 볼륨을 재사용
    • 데이터가 보존되어야하거나 데이터를 안전하게 보관하는 데 사용
  • Delete(삭제)
    • PV를 삭제하면 PV와 연결된 스토리지 볼륨도 함께 삭제  (EBS 볼륨도 제거)
    • 자원을 효율적으로 관리할 수 있지만, 데이터는 완전히 삭제 -> 복구 불가능
  • Recycle(Kubernetes v1.14 Deprecated)
    • PV 내의 데이터를 삭제

 

스토리지 소개


1. EmptyDir

  • Pod 간에 임시 데이터를 공유하기 위해 사용되는 볼륨 유형
  • EmptyDir은 Pod의 라이프사이클 동안만 데이터를 저장 -> Pod가 삭제되면 데이터도 함께 삭제

2. HostPath

  • 호스트 노드의 파일 시스템 경로를 Pod에 마운트하는 방식 -> 호스트 노드의 파일 시스템에 접근 가능
  • 클러스터 노드의 파일이나 디렉터리에 액세스해야 하는 경우 사용
  • 클러스터 내의 다른 노드에서는 동일한 경로가 존재하지 않을 수 있습니다

3. PV/PVC (Persistent Volume / Persistent Volume Claim):

  • PV와 PVC는 Kubernetes에서 영구적인 데이터 저장을 위해 사용되는 볼륨 관리 시스템
  • PV는 클러스터 내의 스토리지 리소스를 나타내며, 실제 물리적인 스토리지나 네트워크 리소스를 대표
  • PVC는 애플리케이션이 PV를 요청하는 방식으로 사용되며, PVC는 PV와 바인딩되어 애플리케이션에 지속적인 데이터 스토리지를 제공
  • PV와 PVC를 사용하면 애플리케이션과 스토리지의 결합도를 낮출 수 있으며, PV는 클러스터 전체에서 공유될 수 있습니다.

출처 : https://kubetm.github.io/k8s/03-beginner-basic-resource/volume/

 
 
CSI (Contaier Storage Interface)


CSI 드라이버는 Kubernetes 클러스터에서 별도의 컨트롤러 Pod을 통해 동적 프로비저닝을 지원합니다.
CSI가 탄생하게 된 배경을 소개하면 다음과 같습니다.
 
CSI Driver 배경

  • Kubernetes 소스 코드 내에 내장된 AWS EBS provisioner는 Kubernetes release lifecycle 따라 배포
  • provisioner의 새로운 기능을 사용하려면 Kubernetes 버전을 업그레이드해야 하는 제약 사항 발생
  • 이를 극복하기 위해 Kubernetes 개발자들은 Kubernetes 내부에 내장된 provisioner (in-tree)를 완전히 제거
  • 대신, 동적 프로비저닝을 위해 별도의 컨트롤러 Pod을 사용할 수 있도록 설정
  • 이러한 목적으로 도입된 것이 바로 CSI (Container Storage Interface) 드라이버

이를 통해 Kubernetes 버전 업그레이드 없이도 새로운 기능을 사용할 수 있게 되었습니다.

출처 : AWS 문서

Node-specific Volume Limits
- AWS EC2 Type에 따라 볼륨 최대 개수 제한 : 25개 ~ 39개
- KUBE_MAX_PD_VOLS 환경 변수의 값을 설정 후 스케줄러를 재시작하여 한도 변경 가능

t3.medium의 경우 25개로 제한

기본 컨테이너 환경의 임시 파일시스템 사용 테스트


10초 간격으로 /home/pod-out.txt 파일에 저장하는 파드 배포
배포한 파드는 특별한 Volume 설정이 없습니다.
파드를 제거 후 다시 배포

tail로 파일 내용을 확인해보면 기존 내용은 찾아볼 수 없습니다. 즉 이전에 삭제한 파드의 데이터는 모두 제거된 것입니다.
 

hostpath 테스트


- 호스트 Path 를 사용하는 PV/PVC : local-path-provisioner 스트리지 클래스 배포

 
- PV/PVC 를 사용하는 파드 생성

pvc 생성 및 확인
PVC를 사용하는 파드 생성 및 파드 내부 파일 내용 확인
실제 노드의 경로에서 찾아보면 동일한 파일을 찾을 수 있습니다.

파드를 제거 후에도 이전과 다르게 파일이 그대로 남아있음을 볼 수 있습니다.

다음 실습을 위한 리소스 정리

3. AWS EBS Controller 실습

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

  • AWS CSI -> 쿠버네티스 CSI 인터페이스에 맞춰 개발된 AWS 의 CSI
  • AWS CSI를 이용하여 EBS, EFS를 쉽게 사용 가능
  • CSI-Controller -> AWS API를 호출하면서 AWS 스토리지를 관리
  • CSI-Node -> kubelet과 상호작용하면서 AWS스토리지를 pod에 마운트
  • CSI-ConrollerCSI-Node는 pod로 생성되어 동작

설치


aws-ebs-csi-driver 전체 버전 정보와 기본 설치 버전(True) 정보 확인
ISRA 설정 : AWS관리형 정책 AmazonEBSCSIDriverPolicy 사용

EBS CSI드라이버가 AWS API를 사용해야 하므로 CSI-controller pod에 IAM policy를 부여하기 위해 IRSA를 사용합니다.  

완료되면 스택 1개 배포된 것을 볼 수 있습니다.
ISRA 확인
Amazon EBS CSI driver addon 추가 및 확인 / ebs-csi-controller 파드에 6개 컨테이너 확인 / csinodes 확인
gp3 스토리지 클래스 생성

테스트 PV/PVC 와 Pod 생성


PVC 생성
Pod 생성
모니터링 결과 attaching -> attached로 상태가 변하는 것을 볼 수 있다. gp3로 제대로 붙었다.

볼륨 증가 테스트


patch 명령어를 통해 pvc의 용량을 수정한다.
용량이 10기가로 증가된 것을 볼 수 있다. 각 명령어의 수치 반영까지 조금 시간이 소요되는 편이다. aws cli 로 확인하는 것이 가장 빠르게 수치가 적용되어 확인할 수 있었다.

볼륨의 크기는 늘릴 수 있지만 줄일 수 없으니 주의해야한다.

마지막으로 리소스를 정리해준다.

 

4. AWS Volume SnapShots Controller

- Amazon Elastic Block Store (EBS) 볼륨의 스냅샷 생성과 관리를 자동화하는 서비스
- Kubernetes 클러스터에서 Persistent Volume Claim(PVC)을 생성하면 해당 PVC에 대한 EBS 스냅샷이 자동으로 생성
- 스냅샷을 기반으로 새로운 PVC를 생성하거나, 스냅샷을 복원하여 이전 상태로 롤백하는 등의 작업을 수행 가능

Volumesnapshots 컨트롤러 설치


Snapshot CRDs 설치
Common Snapshot Controller 설치
Snapshotclass 설

테스트 PVC/파드 생성


테스트용 파드와 pvc를 생성한다.
파일 내용 추가 저장 확인
VolumeSnapshot 생성
VolumeSnapshot 확인
AWS EBS 스냅샷 확인
강제로 파드와 PVC를 제거하여 장애 상황을 가정한다.

스냅샷으로 복원 테스트

스냅샷에서 PVC 로 복원
파드 생성 후 파일 내용 저장 확인 -> 파드 삭제 전에 기록된 데이터가 남아 있다.
테스트 완료 후 리소스를 정리한다.

AWS EFS Controller

  • Amazon Elastic File System (EFS)를 Kubernetes 클러스터와 통합하여 사용할 수 있도록 도와주는 서비스
  • EFS는 AWS 클라우드에서 관리형 파일 스토리지 서비스로, 여러 가용 영역에서 확장성과 내결함성을 제공
  • 다수의 컨테이너에서 동시에 파일을 공유하고 액세스 가능 -> EKS 클러스터에서 사용하기에 적합
  • AWS EFS Controller를 사용하면 클러스터 내에서 EFS 파일 시스템을 동적으로 프로비저닝하고 관리 가능

EFS 파일시스템 확인 및 EFS Controller 설치


EFS 정보 확인 및 IAM 정책 생성
ISRA 설정 : 고객관리형 정책 AmazonEKS_EFS_CSI_Driver_Policy 사용 -> ISRA 생성 확인
EFS Controller 설치 및 확인
AWS → EFS → 파일 시스템 : 네트워크 → 탑재 대상 ID 를 확인할 수 있다.

EFS 파일시스템을 다수의 파드가 사용하게 설정


EFS 스토리지클래스 생성 및 확인
pv.yaml의 volumeHandle에 EFS id값을 넣어준다.
PV 생성 및 확인
PV를 사용하기 위한 PVC도 생성한다.
파드 생성 및 연동 -> 파드의 /data 데이터는 EFS를 사용하도록 설정됨
파드 정보 확인
파드 내의 /data/out1.txt와 작업용 ec2의 /mnt/myefs/out1.txt는 같은 파일임을 알 수 있다.
실습을 마치고 리소스를 제거한다.

EFS 파일시스템을 다수의 파드가 사용하게 설정 ()Dynamic provisioning using EFS)


-> 현재 fargate node에서는 미지원이라고 한다.

EFS 스토리지클래스 생성 및 확인
PVC/파드 생성 및 확인
PVC/PV 생성 로그 확인
파드 정보 및 공유 저장소 저장 동작 확인
EFS → 액세스 포인트 확인
마찬가지로 실습 후 리소스는 지워준다.

 

3주차 후기

예상은 했지만 스터디양이 엄청나다. 추후에 반드시 복습이 필요하다고 느끼고 있다... 이제 절반 3주차가 지났는데 6주차까지 학습이 끝나면 시간적 여유를 가지고 다시 한 번 학습해보고자 한다.😂