Amazon FSx for Lustre CSI 드라이버 - Amazon EKS

Amazon FSx for Lustre CSI 드라이버

FSx for Lustre 컨테이너 스토리지(CSI) 드라이버에서는 Amazon EKS 클러스터가 FSx for Lustre 파일 시스템의 수명 주기를 관리할 수 있게 해주는 CSI 인터페이스를 제공합니다. 자세한 내용을 알아보려면 FSx for Lustre 사용 설명서를 참조하세요.

이 주제에서는 FSx for Lustre CSI 드라이버를 Amazon EKS 클러스터에 배포하고 제대로 작동하는지 확인하는 방법에 관해 설명합니다. 드라이버는 최신 버전을 사용하는 것이 좋습니다. 사용 가능한 버전은 GitHub의 CSI Specification Compatibility Matrix를 참조하세요.

참고

Fargate에서는 드라이버가 지원되지 않습니다.

사용할 수 있는 파라미터에 대한 자세한 설명과 드라이버의 기능을 보여주는 전체 예제는 GitHub의 FSx for Lustre 컨테이너 스토리지 인터페이스(CSI) 드라이버 프로젝트를 참조하세요.

필수 조건

수행해야 할 사항:

  • AWS Command Line Interface(AWS CLI) 버전 2.12.3 이상 또는 1.27.160 이상이 디바이스나 AWS CloudShell에 설치 및 구성되어 있습니다. 현재 버전을 확인하려면 aws --version | cut -d / -f2 | cut -d ' ' -f1을 사용합니다. macOS용 yum, apt-get 또는 Homebrew와 같은 패키지 관리자는 최신 버전의 AWS CLI보다 여러 버전 이전인 경우가 많습니다. 최신 버전을 설치하려면 AWS Command Line Interface 사용 설명서의 AWS CLI 설치, 업데이트 및 제거와 aws configure를 통한 빠른 구성을 참조하세요. AWS CloudShell에 설치된 AWS CLI 버전도 최신 버전보다 여러 버전 이전일 수도 있습니다. 업데이트하려면 AWS CloudShell 사용 설명서의 홈 디렉터리에 AWS CLI 설치를 참조하세요.

  • 디바이스 또는 0.172.0에 설치된 버전 AWS CloudShell 이상의 eksctl 명령줄 도구. eksctl을 설치 또는 업그레이드하려면 eksctl 설명서에서 Installation을 참조하세요.

  • 디바이스 또는 AWS CloudShell에 설치된 kubectl 명령줄 도구. 버전은 클러스터의 Kubernetes 버전과 동일하거나 최대 하나 이전 또는 이후의 마이너 버전일 수 있습니다. 예를 들어 클러스터 버전이 1.28인 경우 kubectl 버전 1.27, 1.28 또는 1.29를 함께 사용할 수 있습니다. kubectl을 설치하거나 업그레이드하려면 kubectl 설치 또는 업데이트 부분을 참조하세요.

다음 절차를 수행하면 FSx for Lustre CSI 드라이버를 사용하여 간단한 테스트 클러스터를 생성할 수 있으므로 클러스터의 작동 방식을 살펴볼 수 있습니다. 프로덕션 워크로드에는 테스트 클러스터를 사용하지 않는 것이 좋습니다. 본 자습서에서는 example values를 바꾸라고 언급된 경우를 제외하고는 이를 사용하는 것이 좋습니다. 프로덕션 클러스터의 단계를 완료하는 경우 모든 example value를 바꿀 수 있습니다. 변수가 여러 단계에서 설정 및 사용되고 서로 다른 터미널에 있지 않기 때문에 동일한 터미널에서 모든 단계를 완료하는 것이 좋습니다.

Amazon EKS 클러스터에 FSx for Lustre 드라이버 배포

  1. 나머지 단계에서 사용할 몇 가지 변수를 설정합니다. my-csi-fsx-cluster를 생성하려는 테스트 클러스터의 이름으로 바꾸고, region-code를 테스트 클러스터를 생성하려는 AWS 리전으로 바꿉니다.

    export cluster_name=my-csi-fsx-cluster
export region_code=region-code

  2. 테스트 클러스터를 생성합니다.

    eksctl create cluster \
  --name $cluster_name \
  --region $region_code \
  --with-oidc \
  --ssh-access \
  --ssh-public-key my-key

    클러스터 프로비저닝에는 몇 분 정도 걸립니다. 클러스터를 생성하는 동안 여러 줄의 출력이 표시됩니다. 출력의 마지막 줄은 다음 예제와 유사합니다.

    [✓]  EKS cluster "my-csi-fsx-cluster" in "region-code" region is ready

  3. 다음 명령을 사용하여 드라이버에 대한 Kubernetes 서비스 계정을 생성하고 AmazonFSxFullAccess AWS 관리형 정책을 서비스 계정에 연결합니다. 클러스터가 AWS GovCloud(미국 동부) 또는 AWS GovCloud(미국 서부) AWS 리전에 있는 경우 arn:aws:를 arn:aws-us-gov:로 바꿉니다.

    eksctl create iamserviceaccount \
  --name fsx-csi-controller-sa \
  --namespace kube-system \
  --cluster $cluster_name \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonFSxFullAccess \
  --approve \
  --role-name AmazonEKSFSxLustreCSIDriverFullAccess \
  --region $region_code

    서비스 계정이 생성되면 여러 줄의 출력이 표시됩니다. 출력의 마지막 줄은 다음과 유사합니다.

    [ℹ]  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-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ]  deploying stack "eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ]  waiting for CloudFormation stack "eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ]  created serviceaccount "kube-system/fsx-csi-controller-sa"

    배포된 AWS CloudFormation 스택의 이름을 기록합니다. 이전 예제 출력에서 스택의 이름이 eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa로 지정되어 있습니다.

  4. 다음 명령을 사용하여 드라이버를 배포합니다. release-X.XX를 원하는 브랜치로 바꿉니다. 마스터 브랜치는 현재 릴리스된 안정적 버전의 드라이버와 호환되지 않는 향후 기능을 포함할 수 있으므로 지원되지 않습니다. 릴리스된 최신 버전을 사용하는 것이 좋습니다. 활성 브랜치 목록은 GitHub의 aws-fsx-csi-driver 섹션을 참조하세요.

    참고

    GitHub의 aws-fsx-csi-driver에서 적용되는 내용을 볼 수 있습니다.

    kubectl apply -k "github.com/kubernetes-sigs/aws-fsx-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-X.XX"

    예제 출력은 다음과 같습니다.

    serviceaccount/fsx-csi-controller-sa created
serviceaccount/fsx-csi-node-sa created
clusterrole.rbac.authorization.k8s.io/fsx-csi-external-provisioner-role created
clusterrole.rbac.authorization.k8s.io/fsx-external-resizer-role created
clusterrolebinding.rbac.authorization.k8s.io/fsx-csi-external-provisioner-binding created
clusterrolebinding.rbac.authorization.k8s.io/fsx-csi-resizer-binding created
deployment.apps/fsx-csi-controller created
daemonset.apps/fsx-csi-node created
csidriver.storage.k8s.io/fsx.csi.aws.com created

  5. 생성된 역할에 대한 ARN을 기록합니다. 이전에 기록하지 않았고 더 이상 AWS CLI 출력에서 사용할 수 없는 경우 다음을 수행하면 AWS Management Console에서 볼 수 있습니다.

    1. AWS CloudFormation 콘솔(https://console.aws.amazon.com/cloudformation)을 엽니다.

    2. 콘솔이 IAM 역할을 생성한 AWS 리전으로 설정되어 있는지 확인한 다음 스택(Stacks)을 선택합니다.

    3. 이름이 eksctl-my-csi-fsx-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa인 스택을 선택합니다.

    4. 출력 탭을 선택합니다. 역할1 ARN이 출력(1) 페이지에 나열됩니다.

  6. 다음 명령을 사용하여 이전에 생성한 서비스 계정을 추가하도록 드라이버 배포를 패치합니다. ARN을 기록해 둔 ARN으로 바꿉니다. 111122223333을 계정 ID로 바꿉니다. 클러스터가 AWS GovCloud(미국 동부) 또는 AWS GovCloud(미국 서부) AWS 리전에 있는 경우 arn:aws:를 arn:aws-us-gov:로 바꿉니다.

    kubectl annotate serviceaccount -n kube-system fsx-csi-controller-sa \
  eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/AmazonEKSFSxLustreCSIDriverFullAccess --overwrite=true

    예제 출력은 다음과 같습니다.

    serviceaccount/fsx-csi-controller-sa annotated
Kubernetes 스토리지 클래스, 영구 볼륨 클레임 및 샘플 애플리케이션을 배포하여 CSI 드라이버가 작동하는지 확인

이 절차에서는 FSx for Lustre Container Storage Interface(CSI) 드라이버 GitHub 리포지토리를 사용하여 동적으로 프로비저닝된 FSx for Lustre 볼륨을 사용합니다.

  1. 클러스터의 보안 그룹을 기록합니다. 이는 네트워킹 섹션 아래의 AWS Management Console에서 또는 다음을 AWS CLI 명령을 사용하여 볼 수 있습니다.

    aws eks describe-cluster --name $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId

  2. Amazon FSx for Lustre 사용 설명서의 Amazon VPC 보안 그룹에 표시된 기준에 따라 Amazon FSx 파일 시스템에 대한 보안 그룹을 생성합니다. VPC의 경우 네트워킹 섹션 아래 표시된 대로 클러스터의 VPC를 선택합니다. “Lustre 클라이언트와 연결된 보안 그룹”의 경우 클러스터 보안 그룹을 사용합니다. 아웃바운드 규칙을 그대로 두어 모든 트래픽을 허용할 수 있습니다.

  3. 다음 명령을 사용하여 스토리지 클래스 매니페스트를 다운로드합니다.

    curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml

  4. storageclass.yaml 파일의 파라미터 섹션을 편집합니다. 모든 example value를 고유한 값으로 바꿉니다.

    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에서 노드 서브넷을 확인할 수 있습니다.

      • 지정한 서브넷이 노드가 있는 서브넷과 다른 경우 VPC가 연결되어 있어야 하며 보안 그룹에 필요한 포트가 열려 있는지 확인해야 합니다.

    • securityGroupIds - 파일 시스템에 대해 생성된 보안 그룹의 ID.

    • deploymentType(선택 사항) - 파일 시스템 배포 유형입니다. 유효한 값은 SCRATCH_1, SCRATCH_2, PERSISTENT_1 및 PERSISTENT_2입니다. 배포 유형에 대한 자세한 내용은 Amazon FSx for Lustre 파일 시스템 생성을 참조하세요.

    • 기타 파라미터(선택 사항) - 기타 파라미터에 대한 자세한 내용을 알아보려면 GitHub의 StorageClass 편집을 참조하세요.

  5. 스토리지 클래스 매니페스트를 생성합니다.

    kubectl apply -f storageclass.yaml

    예제 출력은 다음과 같습니다.

    storageclass.storage.k8s.io/fsx-sc created

  6. 영구 볼륨 클레임 매니페스트를 다운로드합니다.

    curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/claim.yaml

  7. (선택 사항) claim.yaml 파일을 편집합니다. 스토리지 요구 사항과 이전 단계에서 선택한 deploymentType에 따라 1200Gi를 다음 증분 값 중 하나로 변경합니다.

    storage: 1200Gi

    • SCRATCH_2 및 PERSISTENT - 1.2 TiB, 2.4 TiB 또는 2.4TiB 대비 2.4TiB씩 증가합니다.

    • SCRATCH_1 - 1.2 TiB, 2.4 TiB, 3.6 TiB 또는 3.6TiB 대비 3.6TiB씩 증가합니다.

  8. 영구 볼륨 클레임을 생성합니다.

    kubectl apply -f claim.yaml

    예제 출력은 다음과 같습니다.

    persistentvolumeclaim/fsx-claim created

  9. 파일 시스템이 프로비저닝되었는지 확인합니다.

    kubectl describe pvc

    예제 출력은 다음과 같습니다.

    Name:          fsx-claim
Namespace:     default
StorageClass:  fsx-sc
Status:        Bound
[...]
    참고

    Status는 Bound로 변경되기 전에 5~10분 동안 Pending으로 표시될 수 있습니다. Status가 Bound가 될 때까지 다음 단계를 계속하지 마십시오. Status에 10분 이상 동안 Pending이 표시되는 경우 모든 문제를 해결하기 위한 참조로 Events의 경고 메시지를 사용합니다.

  10. 샘플 애플리케이션을 배포합니다.

    kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml

  11. 샘플 애플리케이션이 실행 중인지 확인합니다.

    kubectl get pods

    예제 출력은 다음과 같습니다.

    NAME      READY   STATUS              RESTARTS   AGE
fsx-app   1/1     Running             0          8s

  12. 파일 시스템이 애플리케이션에 의해 올바르게 탑재되었는지 확인합니다.

    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

  13. 샘플 앱에서 데이터가 FSx for Lustre 파일 시스템에 작성되었는지 확인합니다.

    kubectl exec -it fsx-app -- ls /data

    예제 출력은 다음과 같습니다.

    out.txt

    이 출력 예는 샘플 앱이 파일 시스템에 out.txt 파일을 성공적으로 기록했다는 것을 보여줍니다.

참고

클러스터를 삭제하기 전에 FSx for Lustre 파일 시스템을 삭제해야 합니다. 자세한 내용은 FSx for Lustre 사용 설명서의 리소스 정리를 참조하세요.