Pod 및 컨테이너는 본질적으로 임시 또는 일시적이며 스테이트리스(stateless) 애플리케이션을 위해 설계되었습니다. 임시 스토리지를 사용하면 관리자와 개발자가 일부 작업을 위해 로컬 스토리지를 보다 효과적으로 관리할 수 있습니다. 임시 스토리지 개요, 유형 및 관리에 대한 자세한 내용은 임시 스토리지 이해 를 참조하십시오.

컨테이너에 배포된 상태 저장 애플리케이션에는 영구 스토리지가 필요합니다. AWS의 Red Hat OpenShift Service는 PV(영구 볼륨)라는 사전 프로비저닝된 스토리지 프레임워크를 사용하여 클러스터 관리자가 영구 스토리지를 프로비저닝할 수 있도록 합니다. 이러한 볼륨 내의 데이터는 개별 Pod의 라이프사이클을 초과할 수 있습니다. 개발자는 PVC(영구 볼륨 클레임)를 사용하여 스토리지 요구 사항을 요청할 수 있습니다. 영구 스토리지 개요, 구성 및 라이프사이클에 대한 자세한 내용은 영구 스토리지 이해 를 참조하십시오.

임시 스토리지에 대한 제한 및 요청은 바이트 수량으로 측정됩니다. 스토리지를 일반 정수로 표현하거나 E, P, T, G, M, k 접미사 중 하나를 사용하여 고정 소수점 숫자로 표시할 수 있습니다. Ei, Pi, Ti, Gi, Mi, Ki와 동등한 두 가지 강력한 기능을 사용할 수도 있습니다.

예를 들어 다음 수량은 모두 거의 동일한 값인 1289748, 129e6, 129M 및ECDHEMi를 나타냅니다.

다음 예제 구성 파일은 두 개의 컨테이너가 있는 Pod를 보여줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 1
      limits:
        ephemeral-storage: "4Gi" 2
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

Pod 사양의 설정은 스케줄러가 Pod 예약에 대한 결정을 내리는 방법과 kubelet이 Pod를 제거하는 경우 모두에 영향을 미칩니다.

PVC에 정의된 개발자의 요청에 대한 응답으로 클러스터 관리자는 스토리지 및 일치하는 PV를 프로비저닝하는 하나 이상의 동적 프로비저너를 구성합니다.

PVC를 생성할 때 스토리지의 특정 용량을 요청하고, 필요한 액세스 모드를 지정하며, 스토리지를 설명 및 분류하는 스토리지 클래스를 만듭니다. 마스터의 제어 루프는 새 PVC를 감시하고 새 PVC를 적절한 PV에 바인딩합니다. 적절한 PV가 없으면 스토리지 클래스를 위한 프로비저너가 PV를 1개 생성합니다.

전체 PV의 크기는 PVC 크기를 초과할 수 있습니다. 이는 특히 수동으로 프로비저닝된 PV의 경우 더욱 그러합니다. 초과를 최소화하기 위해 AWS의 Red Hat OpenShift Service는 다른 모든 기준과 일치하는 최소 PV에 바인딩됩니다.

일치하는 볼륨이 없거나 스토리지 클래스에 서비스를 제공하는 사용할 수 있는 프로비저너로 생성할 수 없는 경우 클레임은 영구적으로 바인딩되지 않습니다. 일치하는 볼륨을 사용할 수 있을 때 클레임이 바인딩됩니다. 예를 들어, 수동으로 프로비저닝된 50Gi 볼륨이 있는 클러스터는 100Gi 요청하는 PVC와 일치하지 않습니다. 100Gi PV가 클러스터에 추가되면 PVC를 바인딩할 수 있습니다.

Pod는 클레임을 볼륨으로 사용합니다. 클러스터는 클레임을 검사하여 바인딩된 볼륨을 찾고 Pod에 해당 볼륨을 마운트합니다. 여러 액세스 모드를 지원하는 그러한 볼륨의 경우 Pod에서 클레임을 볼륨으로 사용할 때 적용되는 모드를 지정해야 합니다.

클레임이 있고 해당 클레임이 바인딩되면, 바인딩된 PV는 필요한 동안 사용자의 소유가 됩니다. Pod의 볼륨 블록에 persistentVolumeClaim을 포함하여 Pod를 예약하고 클레임된 PV에 액세스할 수 있습니다.

볼륨 사용 작업이 끝나면 API에서 PVC 오브젝트를 삭제하여 리소스를 회수할 수 있습니다. 클레임이 삭제되었지만 다른 클레임에서 아직 사용할 수 없을 때 볼륨은 해제된 것으로 간주됩니다. 이전 클레임의 데이터는 볼륨에 남아 있으며 정책에 따라 처리되어야 합니다.

영구 볼륨 회수 정책은 해제된 볼륨에서 수행할 작업을 클러스터에 명령합니다. 볼륨 회수 정책은 Retain, Recycle 또는 Delete일 수 있습니다.

PVC(영구 볼륨 클레임)가 삭제되어도 PV(영구 볼륨)는 계속 존재하며 "해제됨"으로 간주됩니다. 그러나 이전 클레임의 데이터가 볼륨에 남아 있으므로 다른 클레임에서 PV를 아직 사용할 수 없습니다.

이제 회수된 PV를 다른 PVC에서 사용할 수 있습니다.

영구 볼륨의 회수 정책을 변경하려면 다음을 수행합니다.

Red Hat OpenShift Service on AWS(ROSA)는 다음과 같은 영구 볼륨 스토리지 옵션을 지원합니다.

ROSA는 다른 스토리지 벤더의 CSI(Container Storage Interface) 호환 볼륨 프로비저너를 사용하여 작동합니다. ROSA 의 CSI 드라이버에 대한 자세한 내용은 CSI 볼륨 구성 을 참조하십시오.

일반적으로 PV(영구 볼륨)에는 특정 스토리지 용량이 있습니다. 이는 PV의 용량 속성을 사용하여 설정됩니다.

현재는 스토리지 용량이 설정 또는 요청할 수 있는 유일한 리소스뿐입니다. 향후 속성에는 IOPS, 처리량 등이 포함될 수 있습니다.

영구 볼륨은 리소스 공급자가 지원하는 방식으로 호스트에 볼륨을 마운트될 수 있습니다. 공급자에 따라 기능이 다르며 각 PV의 액세스 모드는 해당 볼륨에서 지원하는 특정 모드로 설정됩니다. 예를 들어, NFS에서는 여러 읽기-쓰기 클라이언트를 지원할 수 있지만 특정 NFS PV는 서버에서 읽기 전용으로 내보낼 수 있습니다. 각 PV는 특정 PV의 기능을 설명하는 자체 액세스 모드 세트를 가져옵니다.

클레임은 액세스 모드가 유사한 볼륨과 매칭됩니다. 유일하게 일치하는 두 가지 기준은 액세스 모드와 크기입니다. 클레임의 액세스 모드는 요청을 나타냅니다. 따라서 더 많이 부여될 수 있지만 절대로 부족하게는 부여되지 않습니다. 예를 들어, 클레임 요청이 RWO이지만 사용 가능한 유일한 볼륨이 NFS PV(RWO+ROX+RWX)인 경우, RWO를 지원하므로 클레임이 NFS와 일치하게 됩니다.

항상 직접 일치가 먼저 시도됩니다. 볼륨의 모드는 사용자의 요청과 일치하거나 더 많은 모드를 포함해야 합니다. 크기는 예상되는 크기보다 크거나 같아야 합니다. NFS 및 iSCSI와 같은 두 개의 볼륨 유형에 동일한 액세스 모드 세트가 있는 경우 둘 중 하나를 해당 모드와 클레임과 일치시킬 수 있습니다. 볼륨 유형과 특정 유형을 선택할 수 있는 순서는 없습니다.

모드가 동일한 모든 볼륨이 그룹화된 후 크기 오름차순으로 크기가 정렬됩니다. 바인더는 모드가 일치하는 그룹을 가져온 후 크기가 일치하는 그룹을 찾을 때까지 크기 순서대로 각 그룹에 대해 반복합니다.

다음 표에는 액세스 모드가 나열되어 있습니다.

볼륨은 다음 단계 중 하나에서 찾을 수 있습니다.

다음 명령을 실행하여 PV에 바인딩된 PVC의 이름을 볼 수 있습니다.

$ oc get pv <pv-claim>

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: 1
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

선택 사항으로 클레임은 storageClassName 속성에 스토리지 클래스의 이름을 지정하여 특정 스토리지 클래스를 요청할 수 있습니다. PVC와 storageClassName이 동일하고 요청된 클래스의 PV만 PVC에 바인딩할 수 있습니다. 클러스터 관리자는 동적 프로비저너를 구성하여 하나 이상의 스토리지 클래스에 서비스를 제공할 수 있습니다. 클러스터 관리자는 PVC의 사양과 일치하는 PV를 생성할 수 있습니다.

클러스터 관리자는 모든 PVC의 기본 스토리지 클래스도 설정할 수도 있습니다. 기본 스토리지 클래스가 구성된 경우 PVC는 ""로 설정된 StorageClass 또는 storageClassName 주석이 스토리지 클래스를 제외하고 PV에 바인딩되도록 명시적으로 요청해야 합니다.

클레임은 특정 액세스 모드로 스토리지를 요청할 때 볼륨과 동일한 규칙을 사용합니다.

Pod와 같은 클레임은 특정 리소스 수량을 요청할 수 있습니다. 이 경우 요청은 스토리지에 대한 요청입니다. 동일한 리소스 모델이 볼륨 및 클레임에 적용됩니다.

클레임을 볼륨으로 사용하여 Pod 액세스 스토리지 클레임을 사용하는 Pod와 동일한 네임스페이스에 클레임이 있어야 합니다. 클러스터는 Pod의 네임스페이스에서 클레임을 검색하고 이를 사용하여 클레임을 지원하는 PersistentVolume을 가져옵니다. 볼륨은 호스트에 마운트되며, 예를 들면 다음과 같습니다.

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" 1
        name: mypd 2
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim 3

스토리지 클래스는 스토리지 수준 및 사용량을 구분하고 조정하는 데 사용됩니다. 스토리지 클래스를 정의하면 사용자는 동적으로 프로비저닝된 영구 볼륨을 얻을 수 있습니다.

AWS의 Red Hat OpenShift Service가 볼륨을 마운트하고 컨테이너로 전달하기 전에 영구 볼륨 정의의 fsType 매개변수에 의해 지정된 파일 시스템이 볼륨에 포함되어 있는지 확인합니다. 장치가 파일 시스템으로 포맷되지 않으면 장치의 모든 데이터가 삭제되고 장치는 지정된 파일 시스템에서 자동으로 포맷됩니다.

이러한 확인을 통해 AWS에서 Red Hat OpenShift Service를 처음 사용하기 전에 포맷하기 때문에 형식화되지 않은 AWS 볼륨을 영구 볼륨으로 사용할 수 있습니다.

기본적으로 AWS의 Red Hat OpenShift Service는 하나의 노드에 연결된 최대 39개의 EBS 볼륨을 지원합니다. 이 제한은 AWS 볼륨 제한과 일치합니다. 볼륨 제한은 인스턴스 유형에 따라 다릅니다.

in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 추가 스토리지 옵션에 액세스하는 방법에 대한 자세한 내용은 AWS Elastic Block Store CSI Driver Operator 를 참조하십시오.

AWS에서 컨테이너-영구 볼륨을 암호화하기 위해 KMS 키를 정의하면 AWS에 배포할 때 명시적인 규정 준수 및 보안 지침이 있는 경우 유용합니다.

CSI 드라이버는 일반적으로 컨테이너 이미지로 제공됩니다. 이러한 컨테이너는 실행되는 AWS의 Red Hat OpenShift Service를 인식하지 못합니다. AWS의 Red Hat OpenShift Service에서 CSI 호환 스토리지 백엔드를 사용하려면 클러스터 관리자가 AWS의 Red Hat OpenShift Service와 스토리지 드라이버 간에 브리지 역할을 하는 여러 구성 요소를 배포해야 합니다.

다음 다이어그램에서는 AWS 클러스터의 Red Hat OpenShift Service의 Pod에서 실행되는 구성 요소에 대한 대략적인 개요를 제공합니다.

다른 스토리지 백엔드에 대해 여러 CSI 드라이버를 실행할 수 있습니다. 각 드라이버에는 드라이버 및 CSI 등록 기관과 함께 자체 외부 컨트롤러 배포 및 데몬 세트가 필요합니다.

AWS의 Red Hat OpenShift Service는 기본적으로 특정 CSI 드라이버를 설치하여 In-tree 볼륨 플러그인에서 사용할 수 없는 사용자에게 스토리지 옵션을 제공합니다.

지원되는 스토리지 자산에 마운트되는 CSI 프로비저닝 영구 볼륨을 생성하기 위해 AWS의 Red Hat OpenShift Service는 기본적으로 필요한 CSI 드라이버 Operator, CSI 드라이버 및 필요한 스토리지 클래스를 설치합니다. Operator 및 드라이버의 기본 네임스페이스에 대한 자세한 내용은 특정 CSI Driver Operator 설명서를 참조하십시오.

다음 표에서는 Red Hat OpenShift Service on AWS와 함께 설치된 CSI 드라이버와 볼륨 스냅샷 및 크기와 같은 CSI 기능을 설명합니다.

위 표에 나열된 드라이버 외에도 ROSA는 타사 스토리지 벤더의 CSI 드라이버와 함께 작동합니다. Red Hat은 타사 프로비저너 또는 연결된 CSI 드라이버를 감독하지 않으며 벤더는 소스 코드, 배포, 운영 및 Kubernetes 호환성을 완전히 제어합니다. 이러한 볼륨 배포 프로그램은 고객 관리로 간주되며 해당 공급업체는 지원을 제공합니다. 자세한 내용은 AWS의 Red Hat OpenShift Service에 대한 공유 책임을 참조하십시오.

영구 스토리지의 동적 프로비저닝은 CSI 드라이버 및 기본 스토리지 백엔드의 기능에 따라 달라집니다. CSI 드라이버 공급자는 AWS의 Red Hat OpenShift Service에서 스토리지 클래스를 생성하는 방법과 구성에 사용할 수 있는 매개변수를 문서화해야 합니다.

동적 프로비저닝을 사용하도록 생성된 스토리지 클래스를 구성할 수 있습니다.

다음 예시는 템플릿을 변경하지 않고 기본 MySQL 템플릿을 설치합니다.

기본 스토리지 클래스를 관리하면 다음과 같은 여러 가지 목표를 수행할 수 있습니다.

이러한 목표를 달성하기 위해 ClusterCSIDriver 오브젝트에서 spec.storageClassState 필드의 설정을 변경합니다. 이 필드에 가능한 설정은 다음과 같습니다.

oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" 1

기본 스토리지 클래스를 변경하려면 다음 절차를 사용하십시오.

예를 들어 두 개의 스토리지 클래스인 gp3 및 standard 가 있고 기본 스토리지 클래스를 gp3 에서 standard 로 변경하려는 경우.

AWS의 Red Hat OpenShift Service는 AWS EBS CSI 드라이버 를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI(Container Storage Interface) Operator 및 드라이버를 사용할 때는 영구 스토리지 및 CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

AWS EBS 스토리지 자산에 마운트되는 CSI 프로비저닝 PV를 생성하기 위해 AWS의 Red Hat OpenShift Service는 openshift-cluster-csi-drivers 네임스페이스에 기본적으로 AWS EBS CSI Driver Operator (Red Hat Operator) 및 AWS EBS CSI 드라이버를 설치합니다.

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 AWS 사용자 스토리지 옵션에 Red Hat OpenShift Service를 제공합니다.

AWS의 Red Hat OpenShift Service에서 AWS EBS 영구 볼륨을 동적으로 프로비저닝하는 방법에 대한 자세한 내용은 Amazon Elastic Block Store를 사용하는 영구 스토리지를 참조하십시오.

AWS의 Red Hat OpenShift Service는 AWS EFS CSI 드라이버 를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI Operator 및 드라이버를 사용할 때는 영구 스토리지 및 CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

AWS EFS CSI Driver Operator를 설치한 후 AWS의 Red Hat OpenShift Service는 openshift-cluster-csi-drivers 네임스페이스에 기본적으로 AWS EFS CSI Operator 및 AWS EFS CSI 드라이버를 설치합니다. 이렇게 하면 AWS EFS CSI Driver Operator에서 AWS EFS 자산에 마운트되는 CSI 프로비저닝 PV를 생성할 수 있습니다.

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 AWS 사용자 스토리지 옵션에 Red Hat OpenShift Service를 제공합니다.

스토리지 클래스는 스토리지 수준 및 사용량을 구분하고 조정하는 데 사용됩니다. 스토리지 클래스를 정의하면 사용자는 동적으로 프로비저닝된 영구 볼륨을 얻을 수 있습니다.

AWS EFS CSI Driver Operator (Red Hat Operator) 는 설치 후 기본적으로 스토리지 클래스를 생성하지 않습니다. 그러나 AWS EFS 스토리지 클래스를 수동으로 생성할 수 있습니다.

다음 절차에서는 AWS의 Red Hat OpenShift Service에서 EFS 볼륨을 생성하고 구성하는 방법을 설명합니다.

AWS EFS CSI 드라이버는 다른 CSI 드라이버와 다른 형태의 동적 프로비저닝을 지원합니다. 새 PV를 기존 EFS 볼륨의 하위 디렉터리로 프로비저닝합니다. PV는 서로 독립적입니다. 그러나 모두 동일한 EFS 볼륨을 공유합니다. 볼륨이 삭제되면 프로비저닝된 모든 PV도 삭제됩니다. EFS CSI 드라이버는 이러한 각 하위 디렉터리에 대한 AWS 액세스 지점을 생성합니다. AWS AccessPoint 제한으로 인해 단일 StorageClass/EFS 볼륨에서 1000 PV만 동적으로 프로비저닝할 수 있습니다.

동적 프로비저닝을 설정하는 데 문제가 있는 경우 Amazon Elastic File Storage 문제 해결을 참조하십시오.

동적 프로비저닝 없이 Amazon EFS(Elastic File Storage) 볼륨을 단일 PV로 사용할 수 있습니다. 전체 볼륨이 pod에 마운트됩니다.

정적 PV를 설정하는 데 문제가 있는 경우 Amazon Elastic File Storage 문제 해결을 참조하십시오.

다음 정보는 Amazon Elastic File Storage(Amazon EFS) 보안에 중요합니다.

예를 들어 앞에서 설명한 대로 동적 프로비저닝을 사용하여 액세스 지점을 사용하는 경우 Amazon은 파일의 GID를 액세스 지점의 GID로 자동으로 대체합니다. 또한 EFS는 파일 시스템 권한을 평가할 때 액세스 지점의 사용자 ID, 그룹 ID 및 보조 그룹 ID를 고려합니다. EFS는 NFS 클라이언트의 ID를 무시합니다. 액세스 지점에 대한 자세한 내용은 https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html 을 참조하십시오.

결과적으로 EFS 볼륨은 FSGroup을 자동으로 무시합니다. AWS의 Red Hat OpenShift Service는 볼륨의 파일 GID를 FSGroup으로 교체할 수 없습니다. 마운트된 EFS 액세스 지점에 액세스할 수 있는 모든 Pod는 해당 노드의 모든 파일에 액세스할 수 있습니다.

이와 무관하게 전송 중 암호화는 기본적으로 활성화되어 있습니다. 자세한 내용은 https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html을 참조하십시오.

다음 정보는 Amazon EFS(Elastic File Storage) 문제 해결 방법에 대한 지침을 제공합니다.

모든 EFS PV는 AWS EFS CSI Driver Operator (Red Hat Operator)를 설치 제거한 후 액세스할 수 없습니다.

다음 리소스는 스토리지 클래스를 구성하는 데 사용되는 매개변수 및 기본값을 보여줍니다. 이 예에서는 AWS ElasticBlockStore (EBS) 객체 정의를 사용합니다.

kind: StorageClass 1
apiVersion: storage.k8s.io/v1 2
metadata:
  name: <storage-class-name> 3
  annotations: 4
    storageclass.kubernetes.io/is-default-class: 'true'
    ...
provisioner: kubernetes.io/aws-ebs 5
parameters: 6
  type: gp3
...

스토리지 클래스를 클러스터 전체 기본값으로 설정하려면 스토리지 클래스의 메타데이터에 다음 주석을 추가합니다.

storageclass.kubernetes.io/is-default-class: "true"

예를 들면 다음과 같습니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
...

이렇게 하면 특정 스토리지 클래스를 지정하지 않은 모든 PVC(영구 볼륨 클레임)가 기본 스토리지 클래스를 통해 자동으로 프로비저닝됩니다. 그러나 클러스터는 두 개 이상의 스토리지 클래스를 보유할 수 있지만, 이 중 하나만 기본 스토리지 클래스일 수 있습니다.

스토리지 클래스 설명을 설정하려면 스토리지 클래스의 메타데이터에 다음 주석을 추가합니다.

kubernetes.io/description: My Storage Class Description

예를 들면 다음과 같습니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: My Storage Class Description
...