FSx for Lustre 드라이버 배포하기
FSx for Lustre 드라이버 배포하기 (Deploy the FSx for Lustre driver)
이 주제는 FSx for Lustre CSI 드라이버를 Amazon EKS 클러스터에 배포하고 정상 동작을 확인하는 방법을 보여줘요. 최신 버전의 드라이버를 사용하는 것을 권장해요. 사용 가능한 버전은 GitHub의 CSI Specification Compatibility Matrix를 참고하세요.
참고
이 드라이버는 Fargate에서 지원되지 않아요.
사용 가능한 매개변수에 대한 자세한 설명과 드라이버 기능을 보여주는 완전한 예시는 GitHub의 FSx for Lustre CSI(Container Storage Interface) 드라이버 프로젝트를 참고하세요.
출처: 문서
본문
사전 요구 사항 (Prerequisites)
- 기존 클러스터.
- Amazon FSx CSI Driver EKS 추가 기능은 EKS Pod Identity 또는 서비스 계정용 IAM 역할(IRSA) 중 하나를 통해 인증을 지원해요. EKS Pod Identity를 사용하려면 FSx CSI Driver 추가 기능을 배포하기 전이나 후에 Pod Identity 에이전트를 설치해요. 자세한 내용은 Amazon EKS Pod Identity Agent 설정하기를 참고하세요. 대신 IRSA를 사용하려면 클러스터용 IAM OIDC 프로바이더 생성하기를 참고하세요.
- 기기 또는 AWS CloudShell에 AWS CLI 버전
2.12.3이상 또는 버전1.27.160이상이 설치되고 구성되어 있어야 해요. 현재 버전을 확인하려면aws --version | cut -d / -f2 | cut -d ' ' -f1을 사용하세요.yum,apt-get, macOS용 Homebrew 같은 패키지 관리자는 최신 AWS CLI보다 몇 버전 뒤처진 경우가 많아요. 최신 버전을 설치하려면 AWS Command Line Interface 사용 설명서의 aws configure로 설치 및 빠른 구성하기를 참고하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 몇 버전 뒤처질 수 있어요. 업데이트하려면 AWS CloudShell 사용 설명서의 홈 디렉터리에 AWS CLI 설치하기를 참고하세요. - 기기 또는 AWS CloudShell에
eksctl명령줄 도구 버전0.215.0이상이 설치되어 있어야 해요.eksctl을 설치하거나 업데이트하려면eksctl문서의 Installation(설치)을 참고하세요. - 기기 또는 AWS CloudShell에
kubectl명령줄 도구가 설치되어 있어야 해요. 버전은 클러스터의 Kubernetes 버전과 같거나 최대 한 마이너 버전 앞뒤일 수 있어요. 예를 들어 클러스터 버전이1.29라면kubectl버전1.28,1.29,1.30을 사용할 수 있어요.kubectl을 설치하거나 업그레이드하려면 kubectl 및 eksctl 설정하기를 참고하세요.
1단계: IAM 역할 생성
Amazon FSx CSI 플러그인은 여러분을 대신해 AWS API를 호출하기 위해 IAM 권한이 필요해요.
참고
IMDS 접근을 차단하지 않는 한 Pod는 IAM 역할에 할당된 권한에 접근할 수 있어요. 자세한 내용은 모범 사례로 Amazon EKS 클러스터 보안하기를 참고하세요.
다음 절차는 IAM 역할을 만들고 AWS 관리형 정책을 연결하는 방법을 보여줘요.
다음 명령으로 IAM 역할을 만들고 AWS 관리형 정책을 연결해요. my-cluster를 사용하려는 클러스터 이름으로 바꾸세요. 이 명령은 IAM 역할을 만들고 IAM 정책을 연결하는 AWS CloudFormation 스택을 배포해요.
eksctl create iamserviceaccount \
--name fsx-csi-controller-sa \
--namespace kube-system \
--cluster my-cluster \
--role-name AmazonEKS_FSx_CSI_DriverRole \
--role-only \
--attach-policy-arn arn:aws:iam::aws:policy/AmazonFSxFullAccess \
--approve
서비스 계정이 만들어질 때 출력 줄이 여러 개 표시돼요. 출력의 마지막 줄은 다음 예시와 유사해요.
[ℹ] 1 task: {
2 sequential sub-tasks: {
create IAM role for serviceaccount "kube-system/fsx-csi-controller-sa",
create serviceaccount "kube-system/fsx-csi-controller-sa",
} }
[ℹ] building iamserviceaccount stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ] deploying stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ] created serviceaccount "kube-system/fsx-csi-controller-sa"
배포된 AWS CloudFormation 스택의 이름을 기록해 두세요. 이전 예시 출력에서 스택 이름은 eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa예요.
이제 Amazon FSx CSI 드라이버 IAM 역할을 만들었으므로 다음 섹션으로 진행할 수 있어요. 이 IAM 역할로 추가 기능을 배포하면 fsx-csi-controller-sa라는 서비스 계정을 만들고 이를 사용하도록 구성돼요. 이 서비스 계정은 필요한 Kubernetes 권한이 할당된 clusterrole에 바인딩돼요.
2단계: Amazon FSx CSI 드라이버 설치
보안을 개선하고 작업량을 줄이려면 Amazon EKS 추가 기능을 통해 Amazon FSx CSI 드라이버를 설치하는 것을 권장해요. 클러스터에 Amazon EKS 추가 기능을 추가하려면 Amazon EKS 추가 기능 생성하기를, 추가 기능에 대한 자세한 내용은 Amazon EKS 추가 기능을 참고하세요.
중요
클러스터의 기존 Amazon FSx CSI 드라이버 설치는 추가 기능 설치 실패를 일으킬 수 있어요. EKS가 아닌 FSx CSI 드라이버가 존재하는 동안 Amazon EKS 추가 기능 버전 설치를 시도하면 리소스 충돌로 인해 설치가 실패해요. 이 문제를 해결하려면 설치 중
OVERWRITE플래그를 사용하세요.aws eks create-addon --addon-name aws-fsx-csi-driver --cluster-name my-cluster --resolve-conflicts OVERWRITE
또는 Amazon FSx CSI 드라이버의 자체 관리형 설치는 GitHub의 Installation(설치)을 참고하세요.
3단계: 스토리지 클래스, 영구 볼륨 클레임, 샘플 앱 배포
이 절차는 FSx for Lustre CSI(Container Storage Interface) 드라이버 GitHub 저장소를 사용해 동적으로 프로비저닝된 FSx for Lustre 볼륨을 사용해요.
클러스터의 보안 그룹을 기록해 두세요. AWS Management Console의 Networking 섹션에서 보거나 다음 AWS CLI 명령으로 볼 수 있어요. my-cluster를 사용하려는 클러스터 이름으로 바꾸세요.
aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId
Amazon FSx for Lustre 사용 설명서의 Amazon VPC 보안 그룹에 표시된 기준에 따라 Amazon FSx 파일 시스템용 보안 그룹을 만들어요. VPC에는 Networking 섹션에 표시된 대로 클러스터의 VPC를 선택해요. "Lustre 클라이언트와 연결된 보안 그룹"에는 클러스터 보안 그룹을 사용해요. 아웃바운드 규칙은 모든 트래픽을 허용하도록 그대로 둘 수 있어요.
다음 명령으로 스토리지 클래스 매니페스트를 다운로드해요.
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
storageclass.yaml 파일의 parameters 섹션을 편집해요. 모든 예시 값을 자신의 값으로 바꾸세요.
parameters:
subnetId: subnet-0eabfaa81fb22bcaf
securityGroupIds: sg-068000ccf82dfba88
deploymentType: PERSISTENT_1
automaticBackupRetentionDays: "1"
dailyAutomaticBackupStartTime: "00:00"
copyTagsToBackups: "true"
perUnitStorageThroughput: "200"
dataCompressionType: "NONE"
weeklyMaintenanceStartTime: "7:09:00"
fileSystemTypeVersion: "2.12"
subnetId– Amazon FSx for Lustre 파일 시스템을 만들 서브넷 ID. Amazon FSx for Lustre는 모든 가용 영역에서 지원되지는 않아요. https://console.aws.amazon.com/fsx/ 에서 Amazon FSx for Lustre 콘솔을 열어 사용하려는 서브넷이 지원되는 가용 영역에 있는지 확인하세요. 서브넷은 노드를 포함할 수 있으며, 다른 서브넷이나 VPC일 수도 있어요. AWS Management Console의 Compute 섹션에서 노드 그룹을 선택해 노드 서브넷을 확인할 수 있어요. 지정한 서브넷이 노드가 있는 서브넷과 다르다면 VPC가 연결되어 있어야 하며, 보안 그룹에서 필요한 포트가 열려 있는지 확인해야 해요.securityGroupIds– 파일 시스템에 대해 만든 보안 그룹의 ID.deploymentType(선택 사항) – 파일 시스템 배포 유형. 유효한 값은SCRATCH_1,SCRATCH_2,PERSISTENT_1,PERSISTENT_2예요. 배포 유형에 대한 자세한 내용은 Amazon FSx for Lustre 파일 시스템 생성하기를 참고하세요.- 기타 매개변수(선택 사항) – 다른 매개변수에 대한 정보는 GitHub의 Edit StorageClass를 참고하세요.
스토리지 클래스 매니페스트를 만들어요.
kubectl apply -f storageclass.yaml
예시 출력은 다음과 같아요.
storageclass.storage.k8s.io/fsx-sc created
영구 볼륨 클레임 매니페스트를 다운로드해요.
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/claim.yaml
(선택 사항) claim.yaml 파일을 편집해요. 스토리지 요구사항과 이전 단계에서 선택한 deploymentType에 따라 1200Gi를 다음 증가 값 중 하나로 변경해요.
storage: 1200Gi
SCRATCH_2및PERSISTENT–1.2 TiB,2.4 TiB, 또는 2.4 TiB 이상의 2.4 TiB 증가분.SCRATCH_1–1.2 TiB,2.4 TiB,3.6 TiB, 또는 3.6 TiB 이상의 3.6 TiB 증가분.
영구 볼륨 클레임을 만들어요.
kubectl apply -f claim.yaml
예시 출력은 다음과 같아요.
persistentvolumeclaim/fsx-claim created
파일 시스템이 프로비저닝되었는지 확인해요.
kubectl describe pvc
예시 출력은 다음과 같아요.
Name: fsx-claim
Namespace: default
StorageClass: fsx-sc
Status: Bound
[...]
참고
Status는Bound로 바뀌기 전에 5~10분 동안Pending으로 표시될 수 있어요.Status가Bound가 될 때까지 다음 단계로 진행하지 마세요.Status가 10분 이상Pending으로 표시되면Events의 경고 메시지를 문제 해결의 참고 자료로 사용하세요.
샘플 애플리케이션을 배포해요.
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
샘플 애플리케이션이 실행 중인지 확인해요.
kubectl get pods
예시 출력은 다음과 같아요.
NAME READY STATUS RESTARTS AGE
fsx-app 1/1 Running 0 8s
애플리케이션이 파일 시스템을 올바르게 마운트했는지 확인해요.
kubectl exec -ti fsx-app -- df -h
예시 출력은 다음과 같아요.
Filesystem Size Used Avail Use% Mounted on
overlay 80G 4.0G 77G 5% /
tmpfs 64M 0 64M 0% /dev
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
192.0.2.0@tcp:/abcdef01 1.1T 7.8M 1.1T 1% /data
/dev/nvme0n1p1 80G 4.0G 77G 5% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 6.9G 12K 6.9G 1% /run/secrets/kubernetes.io/serviceaccount
tmpfs 3.8G 0 3.8G 0% /proc/acpi
tmpfs 3.8G 0 3.8G 0% /sys/firmware
샘플 앱이 FSx for Lustre 파일 시스템에 데이터를 썼는지 확인해요.
kubectl exec -it fsx-app -- ls /data
예시 출력은 다음과 같아요.
out.txt
이 예시 출력은 샘플 앱이 out.txt 파일을 파일 시스템에 성공적으로 썼다는 것을 보여줘요.
참고
클러스터를 삭제하기 전에 FSx for Lustre 파일 시스템을 삭제해야 해요. 자세한 내용은 FSx for Lustre 사용 설명서의 리소스 정리하기를 참고하세요.
FSx for Lustre 성능 튜닝
Amazon EKS에서 FSx for Lustre를 사용할 때 노드 초기화 중에 Lustre 튜닝을 적용해 성능을 최적화할 수 있어요. 권장 접근 방식은 launch template 사용자 데이터를 사용해 모든 노드에서 일관된 구성을 보장하는 거예요.
이 튜닝에는 다음이 포함돼요.
- 네트워크 및 RPC 최적화
- Lustre 모듈 관리
- LRU(Lock Resource Unit) 튜닝
- 클라이언트 캐시 제어 설정
- OST 및 MDC용 RPC 제어
이러한 성능 튜닝 구현에 대한 자세한 지침:
- 표준 노드(비-EFA) 성능 최적화는 launch template 사용자 데이터에 추가할 수 있는 완전한 스크립트에 대해 노드에서 Amazon FSx for Lustre 성능 최적화하기(비-EFA)를 참고하세요.
- EFA 지원 노드 성능 최적화는 노드에서 Amazon FSx for Lustre 성능 최적화하기(EFA)를 참고하세요.