King of Back-end

스토리지와 관련된 쿠버네티스 리소스에는 StorageClass, PersistentVolume 이 있습니다.
보통 동적인 스토리지는 원한다면 StorageClass (이하 SC) 를, 정적인 스토리지를 원한다면 PersistentVolume (이하 PV) 을 사용합니다.
 
한편, 파드에서 스토리지 연결을 하려면 PersistentVolumeClaim (이하 PVC) 을 이용해서 SC 나 PV 를 Bound 해주어야 합니다.
AWS EBS 를 사용하게 될 텐데, EBS 만으로는 한계가 있습니다. 
 
바로 하나의 EBS 는 다중 인스턴스 연결이 되지 않는다는 점이죠.
 
예를 들어 EBS 에 데이터를 저장하는 애플리케이션을 Deployment Replica 2 로 배포한다고 가정해보죠.
그리고 파드들은 서로 다른 워커 노드에 배치됩니다.
EBS 는 단일 노드와만 연결이 가능하므로 다른 노드에 배포된 파드는 EBS 를 사용할 수 없습니다.
EBS gp2, gp3 는 단일 연결만 가능하고, EBS io1, io2 는 다중 연결이 가능함
하지만 io1, io2 는 뛰어난 IOPS 성능을 필요로 하는 곳에 사용되고, 가격이 훨씬 비싸기엔 다소 무리가 있어 보임
 
즉, Pod2 는 계속해서 Pending 상태에 빠지게 될 겁니다.
 
이런 문제를 해결하기 위해선 바로 AWS EFS 를 사용해야 합니다. AWS 의 완전 관리형 NFS 서비스라고 생각하시면 됩니다.
EFS 에 대해선 따로 설명하지 않겠습니다. 궁금하다면 여기 클릭
 
그럼 바로 어떻게 쿠버네티스에서 EFS 를 가져다 쓰는 지 알아보도록 하죠!
 
렛츠두더코드~
 
 
EFS CSI Driver 
쿠버네티스에서 EFS 를 사용하기 위해선 필수 선행 작업이 있습니다.
바로 efs-csi-driver 설치 작업 입니다.
 
Amazon EBS Container Storage Interface(CSI) 드라이버는 AWS에서 실행되는 Kubernetes 클러스터가 Amazon EFS 파일 시스템의 수명 주기를 관리할 수 있게 해주는 CSI 인터페이스를 제공합니다.
 
설치 하는 방법이 어렵진 않으나 다소 해야하는 작업이 많으므로 이번 글에서는 이미 설치를 했다고 가정하겠습니다.
 
설치하는 방법은 여기를 참고해주세요!
 
저는 Helm 을 이용해서 설치했고, 버전은 2.3.6 버전입니다.
 
이번 글에선 EFS 루트 디렉터리를 사용하지 않고, Access Point 를 통해 파드와 마운트를 진행할 겁니다.
EFS 루트 디렉터리를 사용하게 되면, 보안상 많이 좋지 않죠. 권한이라도 획득하는 날에는 EFS 에 있는 데이터를 전부 날릴 수 있죠.
 
Access Point 는 대략 이렇게 생겼습니다. (자세하게 알고 싶다면 여기 참조, Access Point 는 다음 글에서 자세히 다뤄보겠습니다.)
 
정적 프로비저닝이라고 하면 미리 생성된 Access Point 를 사용하는 것이고, 동적 프로비저닝이라고 하면 Access Point 를 SC 가 생성한 것을 사용합니다.
 
동적 프로비저닝이라고 해서 EFS 를 생성하는 것이 아님
Access Point 만 동적으로 관리해줌 
공식 문서에서 Access Point 만 동적으로 가능 이라고 명시되어 있는 걸 보면 추후 EFS 도 가능할지도?
 
 
각자 환경에 맞게 사용하면 되지만, 개인적으로 동적 프로비저닝을 더 선호합니다. 왜냐면 Access Point 를 생성하는 것이 이만 귀찮은 작업이 아닙니다 ㅜㅜ
 
만약 서로 연관 없는 파드 10개에서 Access Point 를 통한 스토리지를 사용한다고 했을 때, 
정적 프로비저닝을 사용한다면, 10개의 Access Point 를 테라폼이나 AWS CLI, Console 로 생성해줘야 합니다.
하지만 동적 프로비저닝은 SC 가 알아서 생성해주고 관리해줍니다.
 
그럼 여기서 이런 생각이 들 수 있습니다.
하나의 공통된 Access Point 만들어서 10개의 파드에서 사용하면 되지 않나?
 
나쁘지 않지만, 다음과 같은 문제가 있어요. 
 
아래 파드 3개는 서로 완전히 다른 애플리케이션이지만 하나의 Access Point 쓰고 있어요.
그리고 3개 모두 data.txt 에 중요한 정보를 담고 있죠. 
 
하지만 이렇게 하면 결국 가장 마지막 실행된 파드가 가지고 있는 data.txt 가 overwrite 될 거에요.
즉, 파드1 과 파드2 는 의도치 않게 파드3의 data.txt 를 가지게 되는 거죠.
 
실제로 /data 라는 폴더를 많이 사용하므로 자칫했다가 프로메테우스가 그라파나의 data 를 가지게 되는 불상사가 생기게 되는거죠.
 
그럼 이제 정적 프로비저닝과 동적 프로비저닝을 이용해서 파드와 Access Point 를 연결해보죠.
 
 
정적 프로비저닝
예제는 여기서 볼 수 있습니다.
# Static Provisioning
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv1
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-0556::fsap-0312
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: efs-pvc
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
kind: Pod
apiVersion: v1
metadata:
  name: my-pod
spec:
  serviceAccountName: sd-dev-efs-common-irsa
  containers:
    - name: my-container
      image: amazon/aws-cli
      command: [ "/bin/sh" ]
      args: [ "-c", "while true; do echo hello; sleep 1d;done" ]
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
      volumeMounts:
        - name: my-pv
          mountPath: /efs/fs
  volumes:
    - name: my-pv
      persistentVolumeClaim:
        claimName: efs-pvc
 
만약 efs-csi-driver 를 성공적으로 설치했다면, 위 yaml 로 생성했을 때 pvc 가 pv 와 Bound 된 것을 확인할 수 있습니다.
 
그리고 사용한 Access Point 의 정보입니다. 
 
파드에서 사용하는 디스크 목록입니다. /efs/fs 가 EFS Access Point 와 마운트 되어 있다는 걸 알 수 있습니다.
PVC 에서 Request Capacity 를 5Gi 로 했는데 위 이미지를 보면 8E(엑사) 인 것을 알 수 있습니다.
EFS 의 용량이며, PVC 에서의 Request Capacity 는 여기서 전혀 중요하지 않다는 걸 알 수 있습니다.
단지 PV 와 PVC 가 서로의 Request Capacity 를 보고 Bound 역할을 해주는 것 뿐이죠.
 
 
파드에 접근해서 mountPath 를 살펴보면 해당 Path 는 파드의 uid:gid 가 root:root 임에도 불구하고, 2001:2001 인 것을 확인 할 수 있죠.
 
Access Point 를 이용한 path 에 파일을 생성하더라고 root:root 가 아니고 2001:2001 로 생성됩니다.
 
my-pod2 를 생성하고 똑같은 Access Point 로 연결 해보겠습니다. 그럼 my-pod2 에서도 test.txt 파일을 볼 수 있어야겠죠?
 
아주 좋습니다.
 
동적 프로비저닝은 더 쉬워요. 바로 알아보죠.
 
동적 프로비저닝
예제는 여기서 볼 수 있습니다.
# Dynamic Provisioning
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap # 현재 access point 만 프로비저닝 지원됨
  fileSystemId: fs-0556
  directoryPerms: "775"
  basePath: "/dynamic_provisioning/my-pod" 
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi
---
kind: Pod
apiVersion: v1
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: amazon/aws-cli
      command: [ "/bin/sh" ]
      args: [ "-c", "while true; do echo hello; sleep 1d;done" ]
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
      volumeMounts:
        - name: my-pv
          mountPath: /efs/fs
  volumes:
    - name: my-pv
      persistentVolumeClaim:
        claimName: efs-pvc
 
SC 를 사용하기 때문에 PVC 의 STORAGECLASS 에 efs-sc 가 명시된 걸 확인할 수 있으며 VOLUME 이름이 난수입니다.
 
동적으로 생성된 Access Point 입니다. 
 
gid 와 uid 는 아래와 같이 자동으로 부여됩니다.
 
 
이외 부분은 정적 프로비저닝과 다르지 않습니다.
 
마무리
이렇게 EFS 와 쿠버네티스와의 궁합을 알아봤는데 정말 좋은거 같아요. 특히 SC 를 사용한다면 너무 쉽게 스토리지를 사용할 수 있죠.
EBS 의 단점을 보완할 수 있습니다.
다만 문제는 EFS 는 EBS 보다 비쌉니다. 스토리지 용량 측면에서 EFS 가 3배 더 비쌉니다.
예를 들어 EBS 같은 경우 30Gi 를 썼을 때 3000원 청구 된다면, EFS 는 9000원이 청구됩니다.
 
그러니 EFS 를 사용한다면, 아래 조건을 잘 따져봐야합니다.
Multi AZ 또는 One Zone
프로비저닝 또는 버스트
IA (Infrequent Access)
또 위에선 보안 관련해서 자세히 다루지 않았지만, 파드에 서비스 어카운트를 지정해주어서 특정 IAM Role 만 EFS 의 Access Point 에 접근하게 해야 합니다. 또한 EFS 파일 시스템 정책도 엄격하게 가져갈 필요도 있고요.
 
그러면 오늘은 여기까지~!
            
'DevOps > Kubernetes' 카테고리의 다른 글
[Kubernetes] 암호화하지 않은 시크릿은 물가에 내놓은 아이 - Encrypt ETCD (상편)  (0)
2023.05.14
[Kubernetes] 파드도 결국 평범한 프로세스라구욧!  (0)
2023.05.09
[Kubernetes] 시크릿을 사용하는 다양한 방법 - Secrets  (1)
2023.05.01
[Kubernetes] 파드를 보다 안전하게 - SecurityContext  (2)
2023.04.16
[Kubernetes] 지난 밤 너가 한 짓을 알고 있다! - Audit  (0)
2023.04.02

[Kubernetes] AWS EFS Access Points 와는 궁합도 안봐!

댓글