AWS EKS - Storage - EFS

CloudNet@ 팀의 AWS EKS Workshop Study 2기 - 3주차
# EKS Workshop 참고

• Amazon Elastic File System (EFS)
  • 완전 관리형 서비스
    • Amazon EFS는 완전히 관리되는 서비스로 제공
    • AWS가 클러스터의 파일 시스템 구성, 운영, 백업 및 관리를 담당하여 사용자가 직접 관리할 필요가 없음
  • 다중 AZ 확장성
    • Amazon EFS는 여러 가용 영역에 걸쳐 확장 가능한 파일 시스템을 제공
    • 애플리케이션의 가용성을 높이고 장애 복구 기능을 향상시킬 수 있습니다.
  • 높은 성능
    • Amazon EFS는 다양한 성능 요구 사항에 대응하기 위해 스토리지 용량과 I/O 처리량을 자동으로 조정
    • 애플리케이션의 성능을 향상시키고 스케일링에 필요한 작업을 간소화
  • 강력한 일관성
    • Amazon EFS는 다중 EC2 인스턴스 간에 파일을 공유하고 동시에 액세스할 수 있는 강력한 일관성을 제공
    • 여러 사용자 또는 서버 간의 파일 공유에 이상적

---

 

✅ 실습

• 실습준비

 

• 이렇게 하면 실습 환경이 다음과 같이 변경됩니다:
  
  • Amazon EFS CSI 드라이버에 대한 IAM 역할 만들기
  • Amazon EFS 파일 시스템 만들기

💠 Persistent network storage

• ecommerce 애플리케이션에는 Assets 마이크로서비스의 일부로 이미 deployment  가 생성되어 있음
• Assets 마이크로서비스는 EKS에서 실행되는 웹 서버를 활용
• 웹 서버는 수평적으로 확장되고 파드의 새로운 상태를 선언

---

• Assets 구성 요소는 제품에 대한 정적 이미지를 제공하는 컨테이너이며, 이러한 제품 이미지는 컨테이너 이미지 빌드의 일부로 추가
• 이 설정에서는 팀이 제품 이미지를 업데이트할 때마다 컨테이너 이미지를 다시 생성하고 다시 배포
• 이 실습에서는 컨테이너 이미지를 다시 빌드할 필요 없이 이전 제품 이미지를 업데이트하고 새 제품 이미지를 추가하기 위해 EFS 파일 시스템과 Kubernetes 퍼시스턴트 볼륨을 활용

---

• 초기 볼륨 구성 확인

• 스테이트풀셋의 볼륨 섹션에서 "파드의 수명을 공유하는" EmptyDir 볼륨 유형만 사용하고 있음

• emptyDir 볼륨은 파드가 노드에 할당될 때 처음 생성되며, 해당 파드가 해당 노드에서 실행되는 동안 존재
• 파드의 모든 컨테이너는 emptyDir 볼륨에서 동일한 파일을 읽고 쓸 수 있지만, 해당 볼륨은 각 컨테이너의 동일하거나 다른 경로에 마운트
• 어떤 이유로든 노드에서 파드가 제거되면 emptyDir 의 데이터는 영구적으로 삭제

---

• 컨테이너 빌드의 일부로 컨테이너에 복사된 초기 제품 이미지가 /usr/share/nginx/html/assets 폴더 아래에 있으며, 아래 명령어를 실행하여 확인

• Assets  Deployment 를 확장하여 여러 복제본이 있도록 합니다:

• 첫 번째 파드의 /usr/share/nginx/html/assets 디렉터리에 newproduct.png 라는 새 제품 이미지를 삽입

• 두 번째 파드의 파일 시스템에 새 제품 이미지 newproduct.png 가 없는지 확인

• 새로 생성된 이미지 newproduct.png는 두 번째 파드에 존재하지 않음
• 이 문제를 해결하려면 서비스를 수평으로 확장하면서 다시 배포하지 않고 파일을 업데이트해야 하는 경우 여러 파드에서 공유할 수 있는 파일 시스템이 필요

💠 EFS CSI Driver 

• Kubernetes 클러스터에서 Amazon Elastic File System (EFS)를 사용하기 위한 컨테이너 스토리지 인터페이스
• Kubernetes의 CSI 스펙에 따라 작성되었으며, Amazon EFS와 Kubernetes 간의 통합을 표준화하여 EFS를 사용하여 클러스터 내에서 파일 기반 애플리케이션을 실행하고 관리

• 투명한 스토리지 프로비저닝
  • Kubernetes 클러스터 내에서 Amazon EFS 파일 시스템을 동적으로 프로비저닝
  • 필요에 따라 파일 시스템을 확장하고 축소
• 파일 시스템 마운트
  • Kubernetes Pod 내에서 Amazon EFS 파일 시스템을 마운트하여 애플리케이션에 파일 기반 스토리지를 제공
• Volume 관리
  • Kubernetes에서 볼륨을 관리하는 데 사용되며, 필요한 경우 스냅샷 및 복제와 같은 고급 기능을 제공
• 안전한 데이터 액세스
  • AWS 보안 모범 사례에 따라 인증 및 권한 부여를 수행하여 클러스터의 데이터 보호를 보장

---

• 보안을 개선하고 작업량을 줄이기 위해 Amazon EFS CSI 드라이버를 Amazon EKS 애드온으로 관리

 

• 애드온에 의해 EKS 클러스터에 생성  확인 : 데몬셋은 클러스터의 각 노드에서 파드를 실행

• EFS CSI 드라이버는 동적 및 정적 프로비저닝을 지원
• 현재 동적 프로비저닝은 각 퍼시스턴트볼륨에 대한 액세스 포인트를 생성
• AWS에서 먼저 AWS EFS 파일 시스템을 수동으로 생성해야 하며, 이 파일 시스템을 StorageClass 매개변수에 입력으로 제공
• 정적 프로비저닝의 경우, 먼저 AWS에서 AWS EFS 파일 시스템을 수동으로 생성: 그런 다음 드라이버를 사용하여 컨테이너 내부에 볼륨으로 마운트

---

• EFS 파일 시스템, 마운트 대상 및 필수 보안 그룹을 프로비저닝하고 Amazon EFS 마운트 지점에 대한 인바운드 NFS 트래픽을 허용하는 인바운드 규칙을 미리 프로비저닝

• 사전 프로비저닝된 EFS 파일 시스템을 사용하고 프로비저닝 모드에서 EFS 액세스 포인트를 사용하도록 구성된 StorageClass 개체를 생성
• Kustomize를 사용하여 스토리지 클래스를 생성하고 스토리지 클래스 객체 구성의 매개변수 filesystemid 값에 환경 변수 EFS_ID를 수집

• 사용자 지정을 적용

• 사용된 프로비저너는 EFS CSI 드라이버
• 프로비저닝 모드는 EFS_ID 환경 변수에 내보낸 파일 시스템의 EFS 액세스 포인트 및 ID

💠 Dynamic provisioning using EFS

• 퍼시스턴트 볼륨을 생성하고 생성된 볼륨을 마운트하도록 자산 배포의 자산 컨테이너를 변경
• 먼저 efspvclaim.yaml 파일을 검사하여 파일의 매개 변수와 이전 단계에서 생성한 스토리지 클래스 efs-sc의 특정 스토리지 크기인 5GB에 대한 클레임을 확인

• Assets  서비스 두 가지 방법으로 수정
  
  • Assets  이미지가 저장된 위치에 PVC를 마운트
  • 초기 이미지를 EFS 볼륨에 복사하기 위해 init 컨테이너를 추가

• 배포의 볼륨 마운트를 살펴보면, /usr/share/nginx/html/assets 라는 이름의 볼륨 마운트에 efsvolume 이라는 새 볼륨이 마운트되어 있는 것을 확인

• 이전 단계에서 생성한 퍼시스턴트볼륨클레임(PVC)에 대한 퍼시스턴트볼륨(PV)이 자동으로 생성

• 또한 생성된 퍼시스턴트볼륨클레임(PVC) 확인

• 첫 번째 파드의 에셋 디렉터리 아래에 새 파일 newproduct.png 생성

• 파일이 이제 두 번째 파드에도 존재하는지 확인
• 첫 번째 파드를 통해 파일을 생성했지만 공유 EFS 파일 시스템으로 인해 두 번째 파드도 이 파일에 액세스 가능