Kubernetes를 위한 영구 스토리지 적용하기

이 글은 AWS Storage Blog에 게시된 Persistent storage for Kubernetes by Suman Debnath, Daniel Rubinstein, Anjani Reddy, and Narayana Vemburaj을 한국어 번역 및 편집하였습니다.

상태 저장 애플리케이션이 올바르게 실행되기 위해서는 데이터가 저장되어 유지되고 읽을 수 있어야 합니다. Kubernetes를 사용하여 상태 저장 애플리케이션을 실행할 때 컨테이너, 포드, 또는 노드 충돌이나 종료에 관계없이 상태가 유지되어야 합니다. 이를 위해서는 영구 스토리지, 즉 컨테이너, 포드, 또는 노드의 수명 후에도 지속되는 스토리지가 필요합니다.

이 블로그에서는 Kubernetes 환경에 대한 영구 스토리지 개념과 Kubernetes 세계의 스토리지 옵션을 다룹니다. 호스트/포드/컨테이너 수준에서 장애 또는 종료가 발생할 경우, 데이터의 손실에 대한 우려를 완화할 수 있는 Kubernetes기반의 상태 저장 애플리케이션을 설계하고 구축하는 과정을 안내합니다.

Kubernetes를 위한 영구 스토리지는, 특히 스토리지에 익숙하지 않으면서 Kubernetes를 시작하는 사람에게는 복잡한 주제입니다. 이러한 이유로, 우리는 먼저 개념과 용어를 살펴보고, 실제 사용 사례에 대해 자세히 알아볼 두 개의 블로그 게시물 시리즈를 만들었습니다.

1부 [이 블로그 게시물]: 이 1부에서는 Kubernetes를 위한 영구 스토리지의 개념과 이러한 개념을 Amazon Elastic File System(Amazon EFS)와 Amazon Elastic Kubernetes Service(Amazon EKS)를 사용하여 기본 워크로드에 영구 스토리지로 어떻게 적용하는지에 대해서 다룹니다.
2부: Amazon EKS에서 Kubeflow를 사용하여 실행되며, 영구 스토리지가 요구되는 기계 학습 워크로드의 예를 자세히 살펴봅니다.

Kubernetes의 데이터 지속성

상태 저장 애플리케이션을 실행할 때, 영구 스토리지가 없으면 데이터는 포드 또는 컨테이너의 수명 주기에 연결됩니다. 포드가 충돌하거나 종료되면 데이터는 손실됩니다.

이러한 데이터 손실을 방지하고 Kubernetes에서 상태 저장 애플리케이션을 실행하려면 세 가지 간단한 스토리지 요구 사항을 준수해야 합니다:

스토리지는 포드의 수명 주기에 의존해서는 안 됩니다.
스토리지는 Kubernetes 클러스터의 모든 포드 및 노드에서 사용할 수 있어야 합니다.
스토리지는 충돌이나 애플리케이션 오류에 관계없이 가용성이 높아야 합니다.

Kubernetes볼륨(Kubernetes volumes)

Kubernetes에는 여러 가지 유형의 스토리지 옵션이 있으며, 모두 영구적인 것은 아닙니다.

임시 스토리지(Ephemeral storage)

컨테이너는 temporary filesystem(tmpfs)를 사용하여 파일을 읽고 쓸 수 있습니다. 그러나 임시 스토리지는 세 가지의 저장소 요구 사항을 충족하지 않습니다. 컨테이너가 충돌하는 경우 temporary filesystem은 손실되고, 컨테이너는 깨끗한 상태로 다시 시작됩니다. 또한 여러 컨테이너가 temporary filesystem을 공유할 수 없습니다.

임시 볼륨(Ephemeral volumes)

임시 Kubernetes Volume은 임시 스토리지가 직면한 두 가지 문제를 모두 해결합니다. 임시 Volume의 수명은 Pod와 연결됩니다. 이를 통해 컨테이너를 안전하게 재시작하고 Pod내의 컨테이너간 데이터를 공유할 수 있습니다. 그러나 Pod가 삭제되는 즉시 Volume도 삭제가 되므로, 이는 여전히 세 가지 요구 사항을 충족하지 못합니다.

임시 파일 시스템은 컨테이너의 수명 주기와 연결되어 있습니다. 임시 볼륨은 포드의 수명 주기에 연결됩니다.

스토리지와 포드 분리: 영구 볼륨(Persistent Volumes)

Kubernetes는 Persistent Volumes도 지원합니다. Persistent Volumes을 사용하면 애플리케이션, 컨테이너, 포드, 노드 또는 클러스터 자체의 수명 주기와 관계없이 데이터가 지속됩니다. Persistent Volumes은 앞에서 설명한 세 가지 요구 사항을 충족합니다.

Persistent Volume(PV) 객체는 애플리케이션 데이터를 유지하는 데 사용되는 스토리지 볼륨을 나타냅니다. PV는 Kubernetes Pods의 수명 주기와 별개로 자체의 수명 주기를 가집니다.

PV는 기본적으로 두 가지로 구성됩니다.

PersistentVolume이라고 불리우는 백엔드 기술
Kubernetes에 볼륨을 마운트하는 방법을 알려주는 접근 모드

백엔드 기술(Backend technology)

PV는 추상적인 구성 요소이며, 실제 물리적 스토리지는 어딘 가에서 가져와야 합니다. 다음은 몇 가지 예입니다.

csi: Container Storage Interface(CSI) → (예: Amazon EFS , Amazon EBS , Amazon FSx 등)
iscsi: iSCSI(SCSI over IP) 스토리지
local: 노드에 마운트된 로컬 저장 장치
nfs: 네트워크 파일 시스템(NFS) 스토리지

Kubernetes는 다목적이며 다양한 유형의 PV를 지원합니다. Kubernetes는 연결되는 스토리지 내부에는 신경을 쓰지 않습니다. PV구성 요소를 실제 저장소에 대한 인터페이스로 제공할 뿐입니다.

PV는 다음과 같은 세 가지의 주요 이점이 있습니다.

PV는 Pod의 수명 주기에 구속되지 않습니다: PV객체에 연결된 포드를 삭제해도 해당 PV는 유지됩니다.
앞의 설명은 포드 충돌 시에도 유효합니다: PV 객체는 장애시에도 유지되고 클러스터에서 제거되지 않습니다.
PV는 클러스터 전체에 적용됩니다: 클러스터의 모든 노드에서 실행 중인 모든 포드에서 연결할 수 있습니다.

모든 다양한 백엔드 스토리지 기술들은 고유한 성능 특성과 장단점을 가지고 있습니다. 이러한 이유로, 운영 Kubernetes 환경에서 애플리케이션에 의존하는 다양한 형태의 PV를 볼 수 있습니다.

접근 모드(Access mode)

접근 모드는 PV가 생성될 때 설정되며 Kubernetes가 볼륨을 마운트하는 방법을 알려줍니다. Persistent Volumes은 세 가지의 접근 모드 지원:

ReadWriteOnce: 볼륨은 동시에 하나의 노드에서만 읽기/쓰기를 허용합니다.
ReadOnlyMany: 볼륨은 동시에 여러 노드에서 읽기 전용 모드를 허용합니다.
ReadWriteMany: 볼륨은 동시에 여러 노드에서 읽기/쓰기를 허용합니다.

모든 PersistentVolume 유형이 모든 액세스 모드 를 지원하는 것은 아닙니다.

영구 볼륨 클레임(Persistent volume claims)

Persistent Volume(PV)은 실제 스토리지 볼륨을 나타냅니다. Kubernetes는 PV를 포드에 연결하는데 필요한 추가 추상화 계층인 PersistentVolumeClaim(PVC)을 가지고 있습니다.

PV 는 실제 스토리지 볼륨을 나타내며, PVC는 Pod가 실제 스토리지를 얻기 위해 수행하는 스토리지 요청을 나타냅니다.

PV와 PVC의 구분은 Kubernetes 환경에서 두 가지 유형의 사용자가 있다는 개념과 관련이 있습니다.

Kubernetes 관리자: 이 사용자는 클러스터를 유지 관리하고 운영하며 영구 스토리지와 같은 계산 리소스를 추가합니다.
Kubernetes 애플리케이션 개발자: 이 사용자는 애플리케이션을 개발하고 배포합니다.

간단히 말해서, 개발자는 관리자가 제공하는 계산 리소스를 사용합니다. Kubernetes는 PV객체는 클러스터 관리자 범위에 속하고, 반면에 PVC 객체는 애플리케이션 개발자 범위에 속해야 한다는 개념으로 구축되었습니다.

기본적으로 PV 객체를 직접 Pod에 마운트할 수 없습니다. 이것은 명시적으로 요청되어져야 합니다. 그리고 그 요청은 PVC객체를 생성하고 Pod에 연결함으로써 달성됩니다. 이것이 이 추가 추상화 계층이 존재하는 유일한 이유입니다. PVC와 PV는 1:1의 관계가 있습니다(PV는 하나의 PVC에만 연결될 수 있음).

이 블로그 게시물에는 포드에 영구 스토리지를 연결하는 과정의 데모가 포함되어 있지만, 그 전에 CSI 드라이버에 대한 몇 가지 배경 지식을 제공해야 합니다.

CSI(Container Storage Interface) 드라이버

CSI (Container Storage Interface)는 Kubernetes에서 다양한 스토리지 솔루션을 쉽게 사용할 수 있도록 설계된 추상화입니다. 다양한 스토리지 공급업체는 CSI 표준을 구현하는 자체 드라이버를 개발하여 스토리지 솔루션이 Kubernetes와 함께 작동하도록 할 수 있습니다(연결되는 스토리지 솔루션의 내부에 관계없이). AWS는 Amazon EBS , Amazon EFS 및 Amazon FSx for Lustre 용 CSI 플러그인을 제공하고 있습니다.

정적 프로비저닝(Static provisioning)

“영구 볼륨 클레임” 섹션에서 설명한 바와 같이, 먼저 관리자가 하나 이상의 PV를 생성하고 애플리케이션 개발자는 PVC를 생성합니다. 이를 정적 프로비저닝이라고 합니다. Kubernetes에서 PV 및 PVC를 수동으로 만들어야 하므로 정적 입니다. 대규모 환경에서는 관리하기가 점점 더 어려워질 수 있으며, 특히 수백 개의 PV와 PVC를 관리하는 경우에는 더욱 그렇습니다.

Amazon EFS 파일 시스템을 생성하여 PV객체로 마운트하기 위해, 정적 프로비저닝을 사용하려고 한다고 가정해 보겠습니다. 다음의 과정이 필요합니다.

Kubernetes 관리자의 작업
1. Amazon EFS 파일 시스템 볼륨을 생성합니다.
2. 파일 시스템 ID를 복사하여 PV YAML정의 파일에 붙여 넣습니다.
3. YAML 파일을 사용하여 PV를 생성합니다.
Kubernetes 애플리케이션 개발자의 작업
1. 이 PV를 요청하기 위해 PVC를 만듭니다.
2. Pod YAML정의 파일의 Pod객체에 PVC를 마운트 합니다.

이것은 작동하지만, 대규모 환경에서는 수행하는데 많은 시간이 소요됩니다.

동적 프로비저닝(Dynamic provisioning)

동적 프로비저닝을 사용하면 PV객체를 생성할 필요가 없습니다. 대신에, PVC를 생성할 때 내부적으로 자동으로 생성됩니다. Kubernetes는 Storage Class라는 다른 객체를 사용하여 이를 수행합니다.

Storage Class는 컨테이너 애플리케이션에 사용되는 백엔드 영구 스토리지(예: Amazon EFS 파일 스토리지, Amazon EBS 블록 스토리지 등)의 클래스를 정의하는 추상화입니다.

Storage Class 기본적으로 두 가지를 포함합니다.

이름(Name): 스토리지 클래스 객체를 고유하게 식별하는 이름입니다.
제공자(Provisioner): 연결되는 스토리지 기술을 정의합니다. 예를 들어, provisioner는 Amazon EFS용 efs.csi.aws.com 또는 Amazon EBS용 ebs.csi.aws.com이 될 수 있습니다.

Storage Class 객체는 Kubernetes가 매우 다양한 스토리지 기술을 처리할 수 있는 이유입니다. Pod 관점에서 볼 때, EFS 볼륨, EBS 볼륨, NFS 드라이브 또는 기타 어떤 것이든, 그 Pod는 PVC 객체만 보게 됩니다. 실제 스토리지 기술을 다루는 모든 내부적인 논리는 Storage Class 객체가 사용하는 프로비저너에 의해 구현됩니다.

Amazon EKS 및 Amazon EFS를 사용한 정적 프로비저닝 및 동적 프로비저닝 데모

이제 모든 학습 내용을 실행해 보겠습니다. 이 데모 섹션을 따라 작업 환경을 설정하려면 이 GitHub 페이지를 참조하십시오.

다음 코드 조각에서 5개의 노드가 있는 Amazon EKS 클러스터를 볼 수 있습니다.

$ kubectl get nodes
NAME                                           STATUS   ROLES    AGE    VERSION
ip-192-168-12-218.us-west-1.compute.internal   Ready    <none>   2d3h   v1.21.5-eks-9017834
ip-192-168-24-116.us-west-1.compute.internal   Ready    <none>   2d3h   v1.21.5-eks-9017834
ip-192-168-46-22.us-west-1.compute.internal    Ready    <none>   2d3h   v1.21.5-eks-9017834
ip-192-168-63-240.us-west-1.compute.internal   Ready    <none>   2d3h   v1.21.5-eks-9017834
ip-192-168-7-195.us-west-1.compute.internal    Ready    <none>   2d3h   v1.21.5-eks-9017834

Kubernetes 클러스터의 영구 스토리지로 Amazon EFS 파일 시스템을 사용합니다. 이를 위해서는 먼저 Amazon EFS CSI 드라이버를 설치해야 합니다.

Amazon EFS를 사용한 정적 프로비저닝

(역자 주: 이 블로그 게시물은 독자들이 한눈에 전체적인 과정을 이해할 수 있도록, 전체 실습 과정 GitHub의 일부를 발췌하여서 작성이 되었습니다. 따라서, 전체 과정을 완전하게 실습하기 위해서는 해당 GitHub의 Static Provisioning using Amazon EFS for Amazon EKS를 바탕으로 실습하시는 것을 권장하여 드립니다.)

AWS Management Console에서 먼저 Amazon EFS 파일 시스템(myEFS1)을 생성하고, 다음 단계에서 PV생성하는 동안 필요하므로 FileSystemId를 기록해 두겠습니다.

모든 것을 기본값으로 유지하고 파일 시스템을 만듭니다.

다음으로, PV 매니페스트 파일을 생성하고 새로 생성된 파일 시스템의 FileSystemId 를 제공합니다.

#pv.yaml
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-073d77123471b2917

이전 pv.yaml 파일에서 보듯이, spec.capacity.storage크기를 5Gibibytes로 작성했습니다. 이는PV를 생성할 때 필요하기 때문에 Kubernetes의 요구를 충족하기 위한 자리 표시자 값일 뿐입니다. 우리는 백엔드로 Amazon EFS 파일 시스템을 사용하고 있는데, 이는 완전히 탄력적이고 확장 가능한 파일 시스템이므로, 사용량에 따라 자동으로 확장 또는 축소되므로 용량에 대해 걱정할 필요가 없습니다.

$ kubectl apply -f pv.yaml
persistentvolume/efs-pv created

$ kubectl get pv efs-pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWO            Retain           Available                                   45s

PV 상태는 Available 이지만 아직 아무런 PVC에도 바인딩되지 않았습니다. 다음으로 영구 볼륨 클레임( PVC)을 생성합니다.

#pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 5Gi

$ kubectl apply -f pvc.yaml
persistentvolumeclaim/efs-claim created

이제 PV 및 PVC의 상태를 확인하겠습니다.

$ kubectl get pv efs-pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWO            Retain           Bound    default/efs-claim                           15m

$ kubectl get pvc efs-claim
NAME        STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
efs-claim   Bound    efs-pv   5Gi        RWO                           103s

이제 PV의 상태가 Available에서 Bound로 변경되었습니다. 이는 Kubernetes가 PVC를 사용하여 일치되는 볼륨을 찾을 수 있었고, 볼륨이 바인딩되었음을 의미합니다.

이제 다른 PVC생성을 시도하면 더 이상 PV가 남아 있지 않기 때문에 실패할 것입니다(하나의 PV는 하나의 PVC에 바인딩될 수 있음). 여기서 동적 프로비저닝이 유용합니다. 그 단계로 이동하기 전에 이 PVC를 사용하여 데이터가 유지되는 방식을 보여 주는 샘플 앱( efs-app)을 만들어 보겠습니다.

#pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: efs-app
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 2; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim

$ kubectl apply -f pod.yaml
pod/efs-app created

kubectl을 사용하여 Amazon EFS 파일 시스템에 데이터가 기록되었는지 확인할 수 있습니다.

$ kubectl exec -ti efs-app -- tail -f /data/out.txt
Mon Mar 21 23:33:05 UTC 2022
Mon Mar 21 23:33:07 UTC 2022
Mon Mar 21 23:33:09 UTC 2022

다음은 Static Provisioning에 대한 요약입니다.

Amazon EFS를 사용한 동적 프로비저닝

(역자 주: 이 블로그 게시물은 독자들이 한눈에 전체적인 과정을 이해할 수 있도록, 전체 실습 과정 GitHub의 일부를 발췌하여서 작성이 되었습니다. 따라서, 전체 과정을 완전하게 실습하기 위해서는 해당 GitHub의 Dynamic Provisioning using Amazon EFS for Amazon EKS를 바탕으로 실습하시는 것을 권장하여 드립니다.)

Amazon EFS CSI 드라이버는 동적 프로비저닝과 정적 프로비저닝을 모두 지원합니다. EFS의 경우, 동적 프로비저닝은 내부적으로 각각의 PV에 대한 액세스 포인트를 생성합니다. 즉, Amazon EFS 파일 시스템을 수동으로 생성하고 이를 Storage Class 파라미터에 대한 입력으로 제공해야 합니다.

기본적으로 동적 프로비저닝을 통해 생성된 각 액세스 포인트는 EFS의 다른 디렉터리에 파일을 쓰고, 각 액세스 포인트는 다른 POSIX uid/gid를 사용하여 EFS에 파일을 씁니다. 이를 통해 여러 애플리케이션이 동일한 EFS 볼륨을 영구 스토리지로 사용하면서, 동시에 애플리케이션 간의 격리를 제공할 수 있게 됩니다.

이제 동적 프로비저닝에 사용할 새 Amazon EFS 볼륨(myEFS2)을 생성하겠습니다.

다음으로, Storage Class 를 생성하고 새로 만든 파일 시스템의 FileSystemId를 제공해야 합니다.

#sc.yaml
----
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-073d123fcb71b2917
  directoryPerms: "700"

Storage Class를 생성하고 확인합니다.

$ kubectl apply -f sc.yaml
storageclass.storage.k8s.io/efs-sc created

$ kubectl get sc
NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
efs-sc          efs.csi.aws.com         Delete          Immediate              false                  4s
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  2d5h

“동적 프로비저닝” 섹션에서 언급했듯이, 애플리케이션을 배포하기 전에PV 를 생성할 필요가 없습니다. 따라서, PVC와 Pod를 계속해서 만들 수 있습니다.


#pvc_pod_1.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim-1
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: efs-app-1
spec:
  containers:
    - name: app
      image: centos
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo $(date -u) >> /data/out; sleep 5; done"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: efs-claim-1

PVC 와 Pod를 배포해 보겠습니다.

$ kubectl apply -f pvc_pod_1.yaml
persistentvolumeclaim/efs-claim-1 created
pod/efs-app-1 created

$ kubectl get pvc
NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
efs-claim-1   Bound    pvc-82da05b5-ff85-40a5-8135-50428480fd22   5Gi        RWX            efs-sc         89s

$ kubectl get pv | grep efs-sc
pvc-7994fdce-5711-4346-aefb-85e10155ec7c   5Gi        RWX            Delete

$ kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
efs-app-1   1/1     Running   0          95s

$ kubectl exec -ti efs-app-1 -- tail -f /data/out
Tue Mar 22 00:38:08 UTC 2022
Tue Mar 22 00:38:13 UTC 2022
Tue Mar 22 00:38:18 UTC 2022

이제 볼 수 있듯이, efs-app-1 가 성공적으로 실행되고 있으며, PV는 EFS CSI 드라이버에 의해 자동으로 생성되었습니다. AWS Management Console에서 해당 액세스 포인트를 볼 수 있습니다.

만약 프로세스를 반복하여 다른 애플리케이션(efs-app-2)을 생성하면, 내부에 또 다른 액세스 포인트가 생성되기 때문에 PV에 대해 걱정할 필요가 없습니다.

다음은 Dynamic Provisioning 대한 요약입니다.

정리

모든 연습 작업을 완료한 후에는, 모든 리소스를 삭제해야 합니다.

모든 Kubernetes 리소스(PV, PVC, 포드, 스토리지 클래스 등)를 삭제합니다.

$ kubectl delete -f pod.yaml
$ kubectl delete -f pvc.yaml
$ kubectl delete -f pv.yaml
$ kubectl delete -f pvc_pod_1.yaml
$ kubectl delete -f sc.yaml

UI 또는 CLI를 통해 EFS 파일 시스템( myEFS1 및 myEFS2)을 삭제합니다.
이 GitHub 페이지를 사용하여 처음에 생성한 EKS 클러스터를 삭제합니다.

마무리

이 블로그 게시물에서는 Kubernetes용 영구 스토리지의 몇 가지 기본 원칙을 다루었습니다. 영구 볼륨을 사용하면 포드 충돌 또는 종료에 관계없이 데이터가 지속되는 Kubernetes기반의 상태 저장 애플리케이션을 생성할 수 있습니다. 영구 볼륨은 정적 또는 동적 프로비저닝을 사용하여 프로비저닝할 수 있습니다. Amazon EFS를 기본 스토리지로 사용하는 EKS 클러스터에서 두 가지를 모두 시연했습니다.

이제 모든 기본 사항을 배웠으므로 보다 실용적인 사용 사례로 넘어갈 시간입니다. 이것이 바로 이 블로그 시리즈의 2부 에서 수행할 작업입니다. 여기서는 영구 스토리지를 사용하고 Kubeflow를 이용하는 기계 학습 워크로드를 실행합니다.

이 블로그 게시물을 읽어 주셔서 감사합니다. 컨테이너와 함께 EFS를 사용하는 방법에 대한 추가 자습서를 보려면 amazon-efs-developer-zone Github 리포지토리를 방문하십시오. 의견, 질문 또는 피드백이 있는 경우 아래 의견 섹션에 의견을 남겨주십시오.

AWS 기술 블로그

Kubernetes를 위한 영구 스토리지 적용하기

Kubernetes의 데이터 지속성

스토리지와 포드 분리: 영구 볼륨(Persistent Volumes)

CSI(Container Storage Interface) 드라이버

Amazon EKS 및 Amazon EFS를 사용한 정적 프로비저닝 및 동적 프로비저닝 데모

정리

마무리

주요 링크 모음

팔로우하기