AEWS 3주차. EKS Storage & Node 관리

k8s에서 기본적으로 제공하는 워크로드 타입은 Stateless한 애플리케이션입니다.

즉, 컨테이너는 상태가 없는 애플리케이션이며, pod가 삭제되면 더이상 pod에 저장된 데이터는 확인할 수 없습니다.

pod 내 컨테이너에서 사용되는 스토리지는 Ephemeral(임시) Storage로 pod가 사라지면 함께 사라지기 때문입니다.

만약 하나의 pod 내의 다수의 컨테이너가 pod내에 생성된 Ephemeral Volume을 이용하는 경우에도 마찬가지입니다.

결국 pod가 사라지면 함께 사라지며, pod의 lifecycle에 따라 컨테이너에서 사용하는 데이터 lifecycle도 정해지게 됩니다.

 

그러나 DB를 사용하거나, 문제 발생시 Log 분석등을 위해 데이터를 지속적으로 유지해야 하는 경우가 있습니다.

데이터 손실을 방지하고, Stateful한 애플리케이션을 위해서 스토리지는 아래 조건을 준수해야 합니다.

    1. 스토리지는 pod의 lifecycle에 의존해서는 안됩니다.

    2. 스토리지는 k8s 클러스터의 모든 pod와 node에서 사용할 수 있어야 합니다.

    3. 스토리지는 충돌이나 애플리케이션 오류에 관계없이 가용성이 높아야 합니다.

 

이러한 조건들을 만족하기 위해 k8s에서는 주로 외부의 지속적으로 사용가능한 스토리지 자원에 데이터를 저장합니다.

이 때 연결되는 스토리지를 Persistent Volume이라 부르며, 일반적으로 줄여서 PV라고 호칭하고 있습니다.

PV는 물리적인 공간이 아니라 추상화된 스토리지 공간이며, 실제 물리적 스토리지는 어딘가에서 가져와야 합니다.

 

PV는 k8s에서 생성할 때 Access Mode(접근 모드)도 함께 설정해야 합니다.

Access Mode는 k8s가 PV를 마운트하는 방법을 알려주며, 3가지 모드를 제공하고 있습니다.

다만, 모든 PV가 3가지 모드를 모두 지원하지는 않음으로 워크로드의 스토리지 특징에 맞추어 설정하는 것이 필요합니다.

    - ReadWriteOnce: 볼륨은 동시에 하나의 노드에서만 읽기/쓰기를 허용합니다.

    - ReadOnlyMany: 볼륨은 동시에 여러 노드에서 읽기 전용 모드를 허용합니다.

    - ReadWriteMany: 볼륨은 동시에 여러 노드에서 읽기/쓰기를 허용합니다.

 

 

PV는 실제 스토리지 볼륨을 나타내며 관리자 입장에서의 스토리지 입니다.

사용자 입장에서 K8s는 PV를 pod에 연결하기 위해 PersistentVolumeClaim(PVC)라는 추상화 계층을 사용합니다.

클러스터의 관리자가 PV를 생성하여 데이터 저장소를 준비하면, 사용자는 PVC 요청을 통해 해당 리소스를 사용합니다.

 

기본적으로 PV는 Node에서 PVC는 pod에서 담당하기 때문에, 서로의 Lifecycle이 다르다고 할 수 있습니다.

pod는 사용자에 의해 언제든 생성되고 삭제될 수 있지만, Node는 관리자에 의해 특별히 관리되기 때문입니다.

 

이 때 사용자가 요청하는 PVC와 데이터 저장 공간인 PV는 1:1의 매핑 관계를 가져가며,

PV생성 및 PVC와의 연결 방식에 따라 정적 또는 동적으로 사용이 가능합니다.

 

1. 정적 프로비저닝 (Static Provisioning)

관리자에 의해 PV가 생성되고, 사용자에 의해 PVC가 요청되어 사용합니다.

수동적인 구성으로 대규모 환경에서는 관리가 어려워지기 때문에, 클라우드 환경에서는 잘 사용되지 않습니다.

 

2. 동적 프로비저닝 (Dynamic Provisioning)

PV 객체를 사전에 생성할 필요 없이, 사용자가 PVC를 생성하면 자동으로 PV까지 생성됩니다.

관리자는 k8s에서는 Storage Class를 통해 PV를 생성할 스토리지에 대해 정의하며,

실제로는 Storage Class에 정의된 Provisioner에 의해 사용자가 사용할 수 있는 PV가 생성됩니다.

 

 

K8s에서는 다양한 종류의 스토리지 연계를 위해 Container Storage Interface 제공합니다.

EKS에서 CSI에 맞추어 개발된 CSI Driver를 통해 다양한 AWS의 스토리지 서비스와의 연결을 제공하고 있습니다.

EKS에서 CSI Driver를 통해 스토리지를 할당하는 절차는 다음과 같습니다.

    1) 관리자가 CSI 드라이버를 지정하는 StorageClass를 정의합니다.

    2) 특정 볼륨 유형에 대해 사용자로부터 요청을 받습니다.

    3) Control Loop가 PVC요청을 감시하고 PV가 있는 경우에 볼륨을 할당합니다.

    4) 사용자가 Steateful한 워크로드를 생성하여 PV에 데이터를 저장합니다.

 

EKS에서는 기존 AWS의 스토리지 서비스를 k8s에서 사용할 수 있도록 제공하고 있습니다.

AWS의 스토리지 타입에 따라 성능과 비용, 사용조건이 다르기 때문에, 사용자 환경에 맞는 CSI 선택이 필요합니다.

그 중 대표적으로 볼륨 스토리지인 EBS와 NAS 스토리지인 EFS가 있습니다.

 

1. Amazon EBS CSI driver

 

EBS는 기본적으로 Block 스토리지이기 때문에

node(EC2)와 동일한 AZ에 위치하고, AccessMode는 ReadWriteOnce로 구성해야 하는 제약이 있습니다.

그러나, 온라인 상에서 즉시 사이즈를 추가할수 도 있고,

스토리지의 기본 기능으로 Snapshot을 제공하고 있어, 편리하게 백업 및 복구를 할수도 있습니다.

 

EBS CSI driver는 중요한 2개의 구성요소로 이루어져 있습니다.

    - CSI-Controller : AWS API를 호출하면서 AWS의 스토리지를 관리

    - CSI-Node : kubelet과 상호작용하면서 AWS의 스토리지를 pod에 마운트

 

2. Amazon EFS CSI Driver

 

EFS는 기본적으로 NAS의 형태로, 각 AZ별 Mount Target을 제공함으로 AZ에 상관없이 구성 가능하며,

NAS이기 때문에 AccessMode는 ReadWriteMany를 지원합니다.

 

3. 기타 CSI 드라이버 

 

    1) Amazon FSx for Lustre CSI Driver : 고성능 컴퓨팅을 위한 대용량 파일 시스템

    2) Amazon FSx for NetApp ONTAP CSI Driver : 완전관리형 ONTAP 파일시스템

    3) Amazon File Cache CSI Driver : 데이터 저장 위치와 관계없이 파일 데이터를 처리하는 완전 관리형 고속 Cache

 

관련 실습

-----------------------------------------------------------------------------------------------

이 내용은 AEWS(AWS EKS Workshop Study) 1기의 과제로써 작성되었습니다.

AEWS는 '가시다'님이 속한 CloudNet@에서 진행하는 AWS EKS workshop에 대한 스터디입니다.

매주 일요일마다 소중한 정보를 퍼주시는 '가시다'님께 무한 감사 드립니다.

https://gasidaseo.notion.site/23-AWS-EKS-Workshop-07165aec800042b9ac9357aee18fdf17