EKS 스토리지(Storage) - AEWS 3주차 1

CSI 란?

CSI (Container Storage Interface) Driver는 컨테이너 오케스트레이터(예: Kubernetes)에서 스토리지 시스템과 통합하기 위한 표준화된 인터페이스입니다. 이 드라이버를 사용하면 컨테이너 환경에서 스토리지 볼륨을 관리하고 사용할 수 있습니다.

간단히 말해, CSI Driver는 스토리지 시스템과 컨테이너 오케스트레이터 간의 통신을 가능하게 해주는 소프트웨어입니다. 이를 통해 사용자는 스토리지 볼륨을 컨테이너에 마운트하고 관리할 수 있으며, 스토리지 시스템을 유연하게 교체하거나 업그레이드할 수 있습니다. CSI Driver는 클라우드 네이티브 환경에서 스토리지 관리를 표준화하고 간소화하는 데 도움이 됩니다.

CSI Driver : 출처 - AWS Document

AWS EBS Controller

AWS EBS (Elastic Block Store)는 Amazon Web Services에서 제공하는 블록 스토리지 서비스로, EC2 인스턴스에 지속적인 블록 스토리지를 제공합니다. 안정적이고 고성능의 블록 수준 스토리지로, EC2 인스턴스에 연결하여 사용합니다.

aws-ebs-csi-driver 설치

• EKS add-on으로 aws-ebs-csi-driver를 제공합니다. add-on을 통해서 aws-ebs-csi-driver를 설치합니다.
• ISRA 설정에서 관리형 정책으로는 AmazonEBSCSIDriverPolicy를 사용합니다.
• gp3 스토리지 클래스를 생성하여 ebs.csi.aws.com 프로비저너로 연결합니다.

# 아래는 aws-ebs-csi-driver 전체 버전 정보와 기본 설치 버전(True) 정보 확인
aws eks describe-addon-versions \
    --addon-name aws-ebs-csi-driver \
    --kubernetes-version 1.28 \
    --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" \
    --output text

# ISRA 설정 : AWS관리형 정책 AmazonEBSCSIDriverPolicy 사용
eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster ${CLUSTER_NAME} \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-only \
  --role-name AmazonEKS_EBS_CSI_DriverRole

# ISRA 확인
eksctl get iamserviceaccount --cluster myeks
NAMESPACE        NAME                            ROLE ARN
kube-system     ebs-csi-controller-sa        arn:aws:iam::911283464785:role/AmazonEKS_EBS_CSI_DriverRole
...

# Amazon EBS CSI driver addon 추가
eksctl create addon --name aws-ebs-csi-driver --cluster ${CLUSTER_NAME} --service-account-role-arn arn:aws:iam::${ACCOUNT_ID}:role/AmazonEKS_EBS_CSI_DriverRole --force
kubectl get sa -n kube-system ebs-csi-controller-sa -o yaml | head -5

# 확인
eksctl get addon --cluster ${CLUSTER_NAME}
kubectl get deploy,ds -l=app.kubernetes.io/name=aws-ebs-csi-driver -n kube-system
kubectl get pod -n kube-system -l 'app in (ebs-csi-controller,ebs-csi-node)'
kubectl get pod -n kube-system -l app.kubernetes.io/component=csi-driver

# ebs-csi-controller 파드에 6개 컨테이너 확인
kubectl get pod -n kube-system -l app=ebs-csi-controller -o jsonpath='{.items[0].spec.containers[*].name}' ; echo
ebs-plugin csi-provisioner csi-attacher csi-snapshotter csi-resizer liveness-probe

# csinodes 확인
kubectl get csinodes

# gp3 스토리지 클래스 생성 - Link
kubectl get sc
cat <<EOT > gp3-sc.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gp3
allowVolumeExpansion: true
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
  #iops: "5000"
  #throughput: "250"
  allowAutoIOPSPerGBIncrease: 'true'
  encrypted: 'true'
  fsType: xfs # 기본값이 ext4
EOT
kubectl apply -f gp3-sc.yaml
kubectl get sc
kubectl describe sc gp3 | grep Parameters

PV/PVC 파드 테스트

• ebs 볼륨 타입의 pv,pvc를 생성하고 파드의 볼륨을 연결하여 확인합니다.
• AWS EBS 볼륨도 잘 생성되었는지 확인합니다.

EFS와는 다르게, gp3스토리지 클래스를 지정하여 PVC만 생성하였을때는, Pending 상태이고, 실제로 파드가 해당 PVC를 볼륨으로 사용하는 시점에 PVC의 상태가 Bound가 되고 EBS 볼륨이 생성됩니다.

# PVC 생성
cat <<EOT > awsebs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  storageClassName: gp3
EOT
kubectl apply -f awsebs-pvc.yaml
kubectl get pvc,pv

# 파드 생성
cat <<EOT > awsebs-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  terminationGracePeriodSeconds: 3
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo \$(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-claim
EOT
kubectl apply -f awsebs-pod.yaml

# PVC, 파드 확인
kubectl get pvc,pv,pod
kubectl get VolumeAttachment

# 추가된 EBS 볼륨 상세 정보 확인 
aws ec2 describe-volumes --volume-ids $(kubectl get pv -o jsonpath="{.items[0].spec.csi.volumeHandle}") | jq

# PV 상세 확인 : nodeAffinity 내용의 의미는?
kubectl get pv -o yaml | yh
...
    nodeAffinity:
      required:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.ebs.csi.aws.com/zone
            operator: In
            values:
            - ap-northeast-2b
...

kubectl get node --label-columns=topology.ebs.csi.aws.com/zone,topology.kubernetes.io/zone
kubectl describe node | more

# 파일 내용 추가 저장 확인
kubectl exec app -- tail -f /data/out.txt

# 아래 명령어는 확인까지 다소 시간이 소요됨
kubectl df-pv

## 파드 내에서 볼륨 정보 확인
kubectl exec -it app -- sh -c 'df -hT --type=overlay'
kubectl exec -it app -- sh -c 'df -hT --type=xfs'

AWS 콘솔에서 확인해보면 실제로 4GiB의 용량을 요청한대로 잘 생성되어 있는 것을 확인할 수 있습니다.

EC2 > Elastic Block Store > 볼륨 확인

볼륨 용량 증설

• PVC의 용량을 증가하고 연결된 EBS의 볼륨 용량이 증가되었는지 확인합니다.

PVC의 spec.resources.requests.storage 필드를 수정합니다. 시간이 지나면 PVC와 EBS 의 볼륨이 변경되는 것을 확인할 수 있습니다. 주의할 점은 용량을 늘릴 수 는 있지만, 줄일 수 없습니다.

# 현재 pv 의 이름을 기준하여 4G > 10G 로 증가 : .spec.resources.requests.storage의 4Gi 를 10Gi로 변경
kubectl get pvc ebs-claim -o jsonpath={.spec.resources.requests.storage} ; echo
kubectl get pvc ebs-claim -o jsonpath={.status.capacity.storage} ; echo
4Gi

# 용량 증설 
kubectl patch pvc ebs-claim -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}'

# 확인 : 볼륨 용량 수정 반영이 되어야 되니, 수치 반영이 조금 느릴수 있다
kubectl exec -it app -- sh -c 'df -hT --type=xfs'
# krew 플러그인을 ᄒᆂ가인 
kubectl df-pv 
# ec2 볼륨 확인 
aws ec2 describe-volumes --volume-ids $(kubectl get pv -o jsonpath="{.items[0].spec.csi.volumeHandle}") | jq
Filesystem     Type     Size  Used Avail Use% Mounted on
overlay        overlay   30G  3.8G   27G  13% /

볼륨 용량 증가 확인 : EC2 > EBS > 볼륨

실습 자원 삭제

kubectl delete pod app & kubectl delete pvc ebs-claim

AWS Volume SnapShots Controller

볼륨 스냅샷은 AWS EBS 볼륨의 데이터 상태를 캡처하고 백업하는 기능으로, 볼륨의 데이터를 보존하고 재사용할 수 있도록 합니다.

AWS Volume SnapShots Controller를 사용하면 Kubernetes Snapshot CRD를 통해서 손쉽게 볼륨을 백업 및 복구를 관리 할 수 있습니다

AWS Volume SnapShots Controller 설치

• 볼륨 스냅샷 기능을 정의해논 CRD를 설치합니다(volumesnapshotclasss,volumesnapshotcontents,volumesnapshots)
• Snapshot Controller를 설치합니다.( 볼륨스냅샷 CRD와 EBS의 볼륨스냅샷 중간에서의 인터페이스 역할 )
• Storageclass와 마찬가지로 볼륨스냅샷에서 사용할 vsclass를 생성하고 Snapshot Controller와 연결합니다.

# (참고) EBS CSI Driver에 snapshots 기능 포함 될 것으로 보임
kubectl describe pod -n kube-system -l app=ebs-csi-controller

# Install Snapshot CRDs
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f snapshot.storage.k8s.io_volumesnapshots.yaml,snapshot.storage.k8s.io_volumesnapshotclasses.yaml,snapshot.storage.k8s.io_volumesnapshotcontents.yaml

# CRD 확인 
kubectl api-resources  | grep snapshot
kubectl get crd | grep snapshot
volumesnapshotclasses.snapshot.storage.k8s.io    2024-03-23T09:13:22Z
volumesnapshotcontents.snapshot.storage.k8s.io   2024-03-23T09:13:22Z
volumesnapshots.snapshot.storage.k8s.io          2024-03-23T09:13:22Z


# Install Common Snapshot Controller
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
kubectl apply -f rbac-snapshot-controller.yaml,setup-snapshot-controller.yaml
kubectl get deploy -n kube-system snapshot-controller
kubectl get pod -n kube-system -l app=snapshot-controller

# Install Snapshotclass
curl -s -O https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/snapshot/manifests/classes/snapshotclass.yaml
kubectl apply -f snapshotclass.yaml
kubectl get vsclass # 혹은 volumesnapshotclasses
si-aws-vsc   ebs.csi.aws.com   Delete           1s

볼륨 스냅샷 생성 및 복구 테스트

먼저, 5초 간격으로 date로그를 출력하는 파드를 생성합니다. 볼륨 스냅샷을 생성하고 장애 재현을 위해 파드를 삭제 합니다.

# PVC 생성
cat <<EOT > awsebs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  storageClassName: gp3
EOT
kubectl apply -f awsebs-pvc.yaml


# 파드 생성
cat <<EOT > awsebs-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  terminationGracePeriodSeconds: 3
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo \$(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-claim
EOT
kubectl apply -f awsebs-pod.yaml

# 파일 내용 추가 저장 확인
kubectl exec app -- tail -f /data/out.txt
Sat Mar 23 09:30:32 UTC 2024
Sat Mar 23 09:30:37 UTC 2024
Sat Mar 23 09:30:42 UTC 2024
Sat Mar 23 09:30:47 UTC 2024
Sat Mar 23 09:30:52 UTC 2024
Sat Mar 23 09:30:57 UTC 2024
Sat Mar 23 09:31:02 UTC 2024
Sat Mar 23 09:31:07 UTC 2024
Sat Mar 23 09:31:12 UTC 2024
Sat Mar 23 09:31:17 UTC 2024
Sat Mar 23 09:31:22 UTC 2024

# VolumeSnapshot 생성 : Create a VolumeSnapshot referencing the PersistentVolumeClaim name >> EBS 스냅샷 확인
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/3/ebs-volume-snapshot.yaml
cat ebs-volume-snapshot.yaml | yh
kubectl apply -f ebs-volume-snapshot.yaml

# VolumeSnapshot 확인
kubectl get volumesnapshot
kubectl get volumesnapshot ebs-volume-snapshot -o jsonpath={.status.boundVolumeSnapshotContentName} ; echo
kubectl describe volumesnapshot.snapshot.storage.k8s.io ebs-volume-snapshot
kubectl get volumesnapshotcontents

# VolumeSnapshot ID 확인 
kubectl get volumesnapshotcontents -o jsonpath='{.items[*].status.snapshotHandle}' ; echo

# AWS EBS 스냅샷 확인
aws ec2 describe-snapshots --owner-ids self | jq
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[]' --output table


# app & pvc 제거 : 강제로 장애 재현
kubectl delete pod app && kubectl delete pvc ebs-claim

생성한 볼륨 스냅샷을 통해 다시 PVC로 복원합니다. spec.datasource 필드에 볼륨 스냅샷 정보를 작성합니다.

복원한 PVC를 통해 파드를 생성하고 파드의 출력 로그를 다시 확인합니다.

# 스냅샷에서 PVC 로 복원
kubectl get pvc,pv
cat <<EOT > ebs-snapshot-restored-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-snapshot-restored-claim
spec:
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  dataSource:
    name: ebs-volume-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
EOT
cat ebs-snapshot-restored-claim.yaml | yh
kubectl apply -f ebs-snapshot-restored-claim.yaml

# 확인
kubectl get pvc,pv
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
persistentvolume/pvc-9be32c38-c468-47f9-8a60-3d1007f1c326   4Gi        RWO            Delete           Bound    kube-system/ebs-snapshot-restored-claim   gp3                     5m33s

NAME                                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/ebs-snapshot-restored-claim   Bound    pvc-9be32c38-c468-47f9-8a60-3d1007f1c326   4Gi        RWO            gp3            5m46s

# 파드 생성
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/3/ebs-snapshot-restored-pod.yaml
cat ebs-snapshot-restored-pod.yaml | yh
kubectl apply -f ebs-snapshot-restored-pod.yaml

# 파일 내용 저장 확인 : 파드 삭제 전까지의 저장 기록이 남아 있다. 이후 파드 재생성 후 기록도 잘 저장되고 있다
kubectl exec app -- cat /data/out.txt
...
Sat Dec 24 15:12:24 UTC 2022
Sat Dec 24 15:12:24 UTC 2022
Sat Dec 24 15:24:23 UTC 2022
Sat Dec 24 15:24:23 UTC 2022
...

# 삭제
kubectl delete pod app && kubectl delete pvc ebs-snapshot-restored-claim && kubectl delete volumesnapshots ebs-volume-snapshot

다시 생성한 파드 출력 로그를 보면 09:30-09:39 사이에 텀이 있는 것을 볼 수있습니다.. 해당 시간은 복원된 볼륨을 통해서 파드가 다시 시작되기 전까지의 시간입니다.

볼륨 스냅샷 테스트 : 파드 삭제 전까지의 저장 기록

실습 자원 삭제

kubectl delete pod app && kubectl delete pvc ebs-snapshot-restored-claim && kubectl delete volumesnapshots ebs-volume-snapshot

AWS EFS Controller

Amazon EFS (Elastic File System)는 AWS에서 제공하는 완전 관리형 클라우드 파일 스토리지 서비스로, 여러 EC2 인스턴스에서 공유하여 사용할 수 있는 네트워크 파일 시스템(NFS)을 제공합니다. 데이터의 안정성과 확장성을 보장하며, 프로비저닝 없이 필요한 만큼의 스토리지를 사용할 수 있습니다.

출처 : AWS

출처 - https://dev.to/awscommunity-asean/aws-eks-with-efs-csi-driver-and-irsa-using-cdk-dgc

실습을 위해 사전에 EFS 파일시스템을 생성하고 파일시스템 ID를 확인합니다.

EFS > 파일시스템

efs-csi-controller 설치

• Helm Chart를 통해 efs-csi-controller를 설치합니다. (현재는 EKS add-on으로도 제공한다고 합니다)
• ISRA 설정에서 관리형 정책으로는 AmazonEKS_EFS_CSI_Driver_Policy를 사용합니다.

# EFS 정보 확인 
aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text

# IAM 정책 생성
curl -s -O https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/docs/iam-policy-example.json
aws iam create-policy --policy-name AmazonEKS_EFS_CSI_Driver_Policy --policy-document file://iam-policy-example.json

# ISRA 설정 : 고객관리형 정책 AmazonEKS_EFS_CSI_Driver_Policy 사용
eksctl create iamserviceaccount \
  --name efs-csi-controller-sa \
  --namespace kube-system \
  --cluster ${CLUSTER_NAME} \
  --attach-policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/AmazonEKS_EFS_CSI_Driver_Policy \
  --approve

# ISRA 확인
kubectl get sa -n kube-system efs-csi-controller-sa -o yaml | head -5
eksctl get iamserviceaccount --cluster myeks

# EFS Controller 설치
helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
helm repo update
helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \
    --namespace kube-system \
    --set image.repository=602401143452.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/eks/aws-efs-csi-driver \
    --set controller.serviceAccount.create=false \
    --set controller.serviceAccount.name=efs-csi-controller-sa

# 확인
helm list -n kube-system
kubectl get pod -n kube-system -l "app.kubernetes.io/name=aws-efs-csi-driver,app.kubernetes.io/instance=aws-efs-csi-driver"

EFS PV/PVC 및 파드 테스트

• 파일 시스템 ID를 통해 PV를 사용합니다.
• 스토리지 클래스 생성 시, provisoner는 efs.csi.aws.com로 지정합니다.
• 여러 개의 파드에서 EFS 볼륨을 공유하고 동작을 확인합니다. ( accessModes=ReadWriteMany )

# 파일시스템 ID를 변수로 지정 
EfsFsId=fs-4af69aab

# 모니터링
watch 'kubectl get sc efs-sc; echo; kubectl get pv,pvc,pod'

# 실습 코드 clone
git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git /root/efs-csi
cd /root/efs-csi/examples/kubernetes/multiple_pods/specs && tree

# EFS 스토리지클래스 생성 및 확인
cat storageclass.yaml | yh
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata: 
  name: efs-sc
provisioner: efs.csi.aws.com

kubectl apply -f storageclass.yaml
kubectl get sc efs-sc

# PV 생성 및 확인 : volumeHandle을 자신의 EFS 파일시스템ID로 변경
EfsFsId=$(aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text)
sed -i "s/fs-4af69aab/$EfsFsId/g" pv.yaml

cat pv.yaml | yh
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-00a5cb5c1258214c3

kubectl apply -f pv.yaml
kubectl get pv; kubectl describe pv

# PVC 생성 및 확인
cat claim.yaml | yh
kubectl apply -f claim.yaml
kubectl get pvc

# 파드 생성 및 연동 : 파드 내에 /data 데이터는 EFS를 사용
cat pod1.yaml pod2.yaml | yh
kubectl apply -f pod1.yaml,pod2.yaml
kubectl df-pv

# 파드 정보 확인 : PV에 5Gi 와 파드 내에서 확인한 NFS4 볼륨 크리 8.0E의 차이는 무엇? 파드에 6Gi 이상 저장 가능한가?
kubectl get pods
kubectl exec -ti app1 -- sh -c "df -hT -t nfs4"
kubectl exec -ti app2 -- sh -c "df -hT -t nfs4"
Filesystem           Type            Size      Used Available Use% Mounted on
127.0.0.1:/          nfs4            8.0E         0      8.0E   0% /data

# 공유 저장소 저장 동작 확인
tree /mnt/myefs              # 작업용EC2에서 확인
tail -f /mnt/myefs/out1.txt  # 작업용EC2에서 확인
kubectl exec -ti app1 -- tail -f /data/out1.txt
kubectl exec -ti app2 -- tail -f /data/out2.txt

실습자원 삭제

kubectl delete pod app1 app2
kubectl delete pvc efs-claim && kubectl delete pv efs-pv && kubectl delete sc efs-sc

Instance Store

AWS Instance Store는 EC2 인스턴스에 로컬로 연결된 짧은 수명의 스토리지 볼륨입니다. 이 스토리지는 인스턴스를 시작할 때 함께 제공되며, 해당 인스턴스가 종료될 때 함께 소멸됩니다. AWS Instance Store 일시적인 데이터나 캐시 데이터 등에 사용될 수 있으며, 애플리케이션의 성능을 향상시키기 위해 임시로 사용될 수 있습니다. 그러나 데이터의 영구적인 보관이나 백업에는 적합하지 않으므로, 영구적인 데이터 스토리지에는 Amazon EBS 등의 다른 AWS 스토리지 서비스를 사용하는 것이 좋습니다.

Instance Store 노드 그룹 생성

# 인스턴스 스토어 볼륨이 있는 c5 모든 타입의 스토리지 크기
aws ec2 describe-instance-types \
 --filters "Name=instance-type,Values=c5*" "Name=instance-storage-supported,Values=true" \
 --query "InstanceTypes[].[InstanceType, InstanceStorageInfo.TotalSizeInGB]" \
 --output table
--------------------------
|  DescribeInstanceTypes |
+---------------+--------+
|  c5d.large    |  50    |
|  c5d.12xlarge |  1800  |
...

# 신규 노드 그룹 생성
eksctl create nodegroup --help
eksctl create nodegroup -c $CLUSTER_NAME -r $AWS_DEFAULT_REGION --subnet-ids "$PubSubnet1","$PubSubnet2","$PubSubnet3" --ssh-access \
  -n ng2 -t c5d.large -N 1 -m 1 -M 1 --node-volume-size=30 --node-labels disk=nvme --max-pods-per-node 100 --dry-run > myng2.yaml

cat <<EOT > nvme.yaml
  preBootstrapCommands:
    - |
      # Install Tools
      yum install nvme-cli links tree jq tcpdump sysstat -y

      # Filesystem & Mount
      mkfs -t xfs /dev/nvme1n1
      mkdir /data
      mount /dev/nvme1n1 /data

      # Get disk UUID
      uuid=\$(blkid -o value -s UUID mount /dev/nvme1n1 /data) 

      # Mount the disk during a reboot
      echo /dev/nvme1n1 /data xfs defaults,noatime 0 2 >> /etc/fstab
EOT
sed -i -n -e '/volumeType/r nvme.yaml' -e '1,$p' myng2.yaml
eksctl create nodegroup -f myng2.yaml

# 노드 보안그룹 ID 확인
NG2SGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng2* --query "SecurityGroups[*].[GroupId]" --output text)
aws ec2 authorize-security-group-ingress --group-id $NG2SGID --protocol '-1' --cidr 192.168.1.100/32

# 워커 노드 SSH 접속
N4=<각자 자신의 워커 노드4번 Private IP 지정>
N4=192.168.3.160
ssh ec2-user@$N4 hostname

# 확인
ssh ec2-user@$N4 sudo nvme list
ssh ec2-user@$N4 sudo lsblk -e 7 -d
ssh ec2-user@$N4 sudo df -hT -t xfs
ssh ec2-user@$N4 sudo tree /data
ssh ec2-user@$N4 sudo cat /etc/fstab

# (옵션) max-pod 확인
kubectl describe node -l disk=nvme | grep Allocatable: -A7
Allocatable:
  cpu:                1930m
  ephemeral-storage:  27905944324
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             3068860Ki
  pods:               100
System Info:

# (옵션) kubelet 데몬 파라미터 확인 : --max-pods=29 --max-pods=100
ssh ec2-user@$N4 sudo ps -ef | grep kubelet
root      2972     1  0 16:03 ?        00:00:09 /usr/bin/kubelet --config /etc/kubernetes/kubelet/kubelet-config.json --kubeconfig /var/lib/kubelet/kubeconfig --container-runtime-endpoint unix:///run/containerd/containerd.sock --image-credential-provider-config /etc/eks/image-credential-provider/config.json --image-credential-provider-bin-dir /etc/eks/image-credential-provider --node-ip=192.168.3.131 --pod-infra-container-image=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/eks/pause:3.5 --v=2 --cloud-provider=aws --container-runtime=remote --node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=myeks,alpha.eksctl.io/nodegroup-name=ng2,disk=nvme,eks.amazonaws.com/nodegroup-image=ami-0da378ed846e950a4,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=ng2,eks.amazonaws.com/sourceLaunchTemplateId=lt-030e6043923ce712b --max-pods=29 --max-pods=100

Kubestr을 통한 스토리지 성능 측정

Kubestr은 스토리지 모니터링 및 성능 측정 확인 도구 입니다. local-path 와 NFS 등 스토리지 클래스의 IOPS 차이를 확인합니다.

노드(disk=nvme라벨로 구분)의 local-path 스토리지 클래스로 Instance Store를 볼륨을 IOPS 성능을 측정합니다.

Instance Store 볼륨의 IOPS의 평균 값이 20318이 나오는 것을 볼 수있습니다 일반 EBS의 기본 IOPS의 값이 3000인데, 무려 6-7배 가량 빠른 것을 볼 수 있습니다.

curl -s -O https://raw.githubusercontent.com/wikibook/kubepractice/main/ch10/fio-read.fio
kubestr fio -f fio-read.fio -s local-path --size 10G --nodeselector disk=nvme


(admin-eks@myeks:kube-system) [root@myeks-bastion ~]# kubestr fio -f fio-read.fio -s local-path --size 10G --nodeselector disk=nvme                                 
PVC created kubestr-fio-pvc-gctvg


Pod created kubestr-fio-pod-xrhj9
Running FIO test (fio-read.fio) on StorageClass (local-path) with a PVC of Size (10G)
|
\
-
Elapsed time- 3m42.702736416s
FIO test results:

FIO version - fio-3.36
Global options - ioengine=libaio verify= direct=1 gtod_reduce=

JobName: 
  blocksize= filesize= iodepth= rw=
read:
  IOPS=20309.275391 BW(KiB/s)=81237
  iops: min=16458 max=93867 avg=20318.648438
  bw(KiB/s): min=65832 max=375473 avg=81274.578125

Disk stats (read/write):
  nvme1n1: ios=2433255/10 merge=0/3 ticks=7645888/14 in_queue=7645902, util=99.958282%
  -  OK

실습 삭제

kubectl delete -f local-path-storage.yaml

# 노드그룹 삭제
eksctl delete nodegroup -c $CLUSTER_NAME -n ng2