스토리지

1. PV를 삭제합니다.

   $ oc delete pv <pv-name>

   AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨과 같은 외부 인프라의 연결된 스토리지 자산은 PV가 삭제된 후에도 계속 존재합니다.

2. 연결된 스토리지 자산에서 데이터를 정리합니다.
3. 연결된 스토리지 자산을 삭제합니다. 대안으로, 동일한 스토리지 자산을 재사용하려면, 스토리지 자산 정의를 사용하여 새 PV를 생성합니다.

1. 클러스터의 영구 볼륨을 나열합니다.

   $ oc get pv

   출력 예

   NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
    pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
    pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
    pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3    manual                     3s

2. 영구 볼륨 중 하나를 선택하고 다음과 같이 회수 정책을 변경합니다.

   $ oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

3. 선택한 영구 볼륨에 올바른 정책이 있는지 확인합니다.

   $ oc get pv

   출력 예

   NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
    pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
    pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
    pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3    manual                     3s

   이전 출력에서 default/claim3 클레임에 바인딩된 볼륨이 이제 Retain 회수 정책을 갖습니다. 사용자가 default/claim3 클레임을 삭제할 때 볼륨이 자동으로 삭제되지 않습니다.

1. ReadWriteOnce(RWO) 볼륨은 여러 노드에 마운트할 수 없습니다. 시스템이 이미 실패한 노드에 할당되어 있기 때문에, 노드가 실패하면 시스템은 연결된 RWO 볼륨을 새 노드에 마운트하는 것을 허용하지 않습니다. 이로 인해 다중 연결 오류 메시지가 표시되면 동적 영구 볼륨이 연결된 경우와 같이 중요한 워크로드에서의 데이터가 손실되는 것을 방지하기 위해 종료되거나 충돌이 발생한 노드에서 Pod를 삭제해야 합니다.
2. AWS EBS 기반 Pod에 재생성 배포 전략을 사용합니다.
3. 원시 블록 볼륨만 파이버 채널 및 iSCSI에 대한 RWX(ReadWriteMany) 액세스 모드를 지원합니다. 자세한 내용은 "볼륨 지원 차단"을 참조하십시오.
4. 기본 vSphere 환경에서 vSAN 파일 서비스를 지원하는 경우 OpenShift Container Platform에서 설치한 vSphere CSI(Container Storage Interface) Driver Operator는 RWX(ReadWriteMany) 볼륨의 프로비저닝을 지원합니다. vSAN 파일 서비스가 구성되어 있지 않고 RWX를 요청하면 볼륨이 생성되지 않고 오류가 기록됩니다. 자세한 내용은 "Container Storage Interface" → "VMware vSphere CSI Driver Operator 사용"을 참조하십시오.

절차

1. OpenShift Container Platform 콘솔에서 스토리지 → 영구 볼륨 클레임을 클릭합니다.
2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.

3. 표시되는 페이지에 원하는 옵션을 정의합니다.

   1. 드롭다운 메뉴에서 이전에 생성한 스토리지 클래스를 선택합니다.
   2. 스토리지 클레임의 고유한 이름을 입력합니다.
   3. 액세스 모드를 선택합니다. 이렇게 하면 생성된 스토리지 클레임에 대한 읽기 및 쓰기 액세스가 결정됩니다.
   4. 스토리지 클레임의 크기를 정의합니다.
4. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.

절차

1. 스토리지 클래스를 생성합니다.

   $ cat << EOF | oc create -f -
   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <storage-class-name> 1
   parameters:
     fsType: ext4 2
     encrypted: "true"
     kmsKeyId: keyvalue 3
   provisioner: ebs.csi.aws.com
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   EOF

   1

   스토리지 클래스의 이름을 지정합니다.

   2

   프로비저닝된 볼륨에서 생성된 파일 시스템입니다.

   3

   container-persistent 볼륨을 암호화할 때 사용할 키의 전체 Amazon Resource Name(ARN)을 지정합니다. 키를 제공하지 않지만 암호화된 필드가 true 로 설정된 경우 기본 KMS 키가 사용됩니다. AWS 문서의 키 ID 및 키 ARN 찾기를 참조하십시오.

2. KMS 키를 지정하는 스토리지 클래스를 사용하여 PVC(영구 볼륨 클레임)를 생성합니다.

   $ cat << EOF | oc create -f -
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: mypvc
   spec:
     accessModes:
       - ReadWriteOnce
     volumeMode: Filesystem
     storageClassName: <storage-class-name>
     resources:
       requests:
         storage: 1Gi
   EOF

3. PVC를 사용하도록 워크로드 컨테이너를 생성합니다.

   $ cat << EOF | oc create -f -
   kind: Pod
   metadata:
     name: mypod
   spec:
     containers:
       - name: httpd
         image: quay.io/centos7/httpd-24-centos7
         ports:
           - containerPort: 80
         volumeMounts:
           - mountPath: /mnt/storage
             name: data
     volumes:
       - name: data
         persistentVolumeClaim:
           claimName: mypvc
   EOF

절차

1. OpenShift Container Platform 콘솔에서 스토리지 → 스토리지 클래스를 클릭합니다.
2. 스토리지 클래스 개요에서 스토리지 클래스 만들기를 클릭합니다.

3. 표시되는 페이지에 원하는 옵션을 정의합니다.

   1. 스토리지 클래스를 참조할 이름을 입력합니다.
   2. 선택적 설명을 입력합니다.
   3. 회수 정책을 선택합니다.

   4. 드롭다운 목록에서 kubernetes.io/azure-disk를 선택합니다.

      1. 스토리지 계정 유형을 입력합니다. 이는 Azure 스토리지 계정 SKU 계층에 해당합니다. 유효한 옵션은 Premium_LRS, Standard_LRS, StandardSSD_LRS 및 UltraSSD_LRS입니다.

      2. 계정 종류를 입력합니다. 유효한 옵션은 shared, dedicated 및 managed입니다.

         중요

         Red Hat은 스토리지 클래스에서 kind: Managed의 사용만 지원합니다.

         Shared 및 Dedicated를 사용하여 Azure는 관리되지 않은 디스크를 생성합니다. 반면 OpenShift Container Platform은 머신 OS(root) 디스크의 관리 디스크를 생성합니다. Azure Disk는 노드에서 관리 및 관리되지 않은 디스크를 모두 사용하도록 허용하지 않으므로 Shared 또는 Dedicated로 생성된 관리되지 않은 디스크를 OpenShift Container Platform 노드에 연결할 수 없습니다.

   5. 원하는 대로 스토리지 클래스에 대한 추가 매개변수를 입력합니다.
4. 생성을 클릭하여 스토리지 클래스를 생성합니다.

절차

1. OpenShift Container Platform 콘솔에서 스토리지 → 영구 볼륨 클레임을 클릭합니다.
2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.

3. 표시되는 페이지에 원하는 옵션을 정의합니다.

   1. 드롭다운 메뉴에서 이전에 생성한 스토리지 클래스를 선택합니다.
   2. 스토리지 클레임의 고유한 이름을 입력합니다.
   3. 액세스 모드를 선택합니다. 이렇게 하면 생성된 스토리지 클레임에 대한 읽기 및 쓰기 액세스가 결정됩니다.
   4. 스토리지 클레임의 크기를 정의합니다.
4. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.

절차

1. Azure File 인증 정보가 포함된 Secret 오브젝트를 생성합니다.

   $ oc create secret generic <secret-name> --from-literal=azurestorageaccountname=<storage-account> \ 1
     --from-literal=azurestorageaccountkey=<storage-account-key> 2

   1

   Azure File 스토리지 계정 이름입니다.

   2

   Azure File 스토리지 계정 키입니다.

2. 생성한 Secret 오브젝트를 참조하는 PersistentVolume 오브젝트를 생성합니다.

   apiVersion: "v1"
   kind: "PersistentVolume"
   metadata:
     name: "pv0001" 1
   spec:
     capacity:
       storage: "5Gi" 2
     accessModes:
       - "ReadWriteOnce"
     storageClassName: azure-file-sc
     azureFile:
       secretName: <secret-name> 3
       shareName: share-1 4
       readOnly: false

   1

   영구 볼륨의 이름입니다.

   2

   이 영구 볼륨의 크기입니다.

   3

   Azure File에서 인증 정보를 공유하는 시크릿의 이름입니다.

   4

   Azure File 공유의 이름입니다.

3. 생성한 영구 볼륨에 매핑되는 PersistentVolumeClaim 오브젝트를 생성합니다.

   apiVersion: "v1"
   kind: "PersistentVolumeClaim"
   metadata:
     name: "claim1" 1
   spec:
     accessModes:
       - "ReadWriteOnce"
     resources:
       requests:
         storage: "5Gi" 2
     storageClassName: azure-file-sc 3
     volumeName: "pv0001" 4

   1

   영구 볼륨 클레임의 이름입니다.

   2

   이 영구 볼륨 클레임의 크기입니다.

   3

   영구 볼륨을 프로비저닝하는 데 사용되는 스토리지 클래스의 이름입니다. PersistentVolume 정의에 사용되는 스토리지 클래스를 지정합니다.

   4

   Azure File 공유를 참조하는 기존 PersistentVolume 오브젝트의 이름입니다.

1. 실행 가능한 파일이 클러스터의 모든 노드에 있는지 확인합니다.
2. 볼륨 플러그인 경로에 실행 파일 위치: /etc/kubernetes/kubelet-plugins/volume/exec/<vendor>~<driver>/<driver > .

절차

1. OpenShift Container Platform 콘솔에서 스토리지 → 영구 볼륨 클레임을 클릭합니다.
2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.

3. 표시되는 페이지에 원하는 옵션을 정의합니다.

   1. 드롭다운 메뉴에서 이전에 생성한 스토리지 클래스를 선택합니다.
   2. 스토리지 클레임의 고유한 이름을 입력합니다.
   3. 액세스 모드를 선택합니다. 이렇게 하면 생성된 스토리지 클레임에 대한 읽기 및 쓰기 액세스가 결정됩니다.
   4. 스토리지 클레임의 크기를 정의합니다.
4. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.

절차

1. PV(영구 볼륨)를 정의합니다. PersistentVolume 오브젝트 정의를 사용하여 pv.yaml 파일을 생성합니다.

     apiVersion: v1
     kind: PersistentVolume
     metadata:
       name: task-pv-volume 1
       labels:
         type: local
     spec:
       storageClassName: manual 2
       capacity:
         storage: 5Gi
       accessModes:
         - ReadWriteOnce 3
       persistentVolumeReclaimPolicy: Retain
       hostPath:
         path: "/mnt/data" 4

   1

   볼륨의 이름입니다. 이 이름을 사용하여 영구 볼륨 클레임 또는 Pod에 의해 식별됩니다.

   2

   영구 볼륨 클레임 요청을 이 영구 볼륨에 바인딩하는 데 사용됩니다.

   3

   볼륨은 단일 노드에서 읽기-쓰기로 마운트할 수 있습니다.

   4

   구성 파일은 볼륨이 클러스터 노드의 /mnt/data에 있음을 지정합니다. 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 그러면 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다.

2. 파일에서 PV를 생성합니다.

   $ oc create -f pv.yaml

3. PVC(영구 볼륨 클레임)를 정의합니다. PersistentVolumeClaim 오브젝트 정의를 사용하여 pvc.yaml 파일을 생성합니다.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: task-pvc-volume
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
     storageClassName: manual

4. 파일에서 PVC를 생성합니다.

   $ oc create -f pvc.yaml

절차

1. openshift-local-storage 프로젝트를 생성합니다.

   $ oc adm new-project openshift-local-storage

2. 선택 사항: 인프라 노드에서 로컬 스토리지 생성을 허용합니다.

   Local Storage Operator를 사용하여 로깅 및 모니터링과 같은 구성 요소를 지원하는 인프라 노드에 볼륨을 생성할 수 있습니다.

   Local Storage Operator에 작업자 노드가 아닌 인프라 노드가 포함되도록 기본 노드 선택기를 조정해야 합니다.

   Local Storage Operator가 클러스터 전체 기본 선택기를 상속하지 못하도록 하려면 다음 명령을 입력합니다.

   $ oc annotate namespace openshift-local-storage openshift.io/node-selector=''

3. 선택 사항: 단일 노드 배포의 CPU 관리 풀에서 로컬 스토리지를 실행할 수 있습니다.

   단일 노드 배포에서 Local Storage Operator를 사용하고 관리 풀에 속하는 CPU를 사용할 수 있습니다. 관리 워크로드 파티셔닝을 사용하는 단일 노드 설치에서 이 단계를 수행합니다.

   Local Storage Operator가 관리 CPU 풀에서 실행되도록 다음 명령을 실행합니다.

   $ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'

1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Operators → OperatorHub로 이동합니다.
3. Local Storage를 필터 상자에 입력하여 Local Storage Operator를 찾습니다.
4. 설치를 클릭합니다.
5. Operator 설치 페이지에서 클러스터의 특정 네임스페이스를 선택합니다. 드롭다운 메뉴에서 openshift-local-storage를 선택합니다.
6. 업데이트 채널 및 승인 전략 값을 원하는 값으로 조정합니다.
7. 설치를 클릭합니다.

CLI에서

1. CLI에서 Local Storage Operator를 설치합니다.

   1. openshift-local-storage.yaml과 같은 Local Storage Operator의 Operator 그룹 및 서브스크립션을 정의하는 오브젝트 YAML 파일을 생성합니다.

      예: openshift-local-storage.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: local-operator-group
        namespace: openshift-local-storage
      spec:
        targetNamespaces:
          - openshift-local-storage
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: local-storage-operator
        namespace: openshift-local-storage
      spec:
        channel: stable
        installPlanApproval: Automatic 1
        name: local-storage-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

      1

      설치 계획에 대한 사용자 승인 정책입니다.

2. 다음 명령을 입력하여 Local Storage Operator 오브젝트를 생성합니다.

   $ oc apply -f openshift-local-storage.yaml

   이 시점에서 OLM(Operator Lifecycle Manager)은 Local Storage Operator를 인식합니다. Operator의 ClusterServiceVersion (CSV)이 대상 네임스페이스에 표시되고 Operator가 제공한 API를 작성할 수 있어야 합니다.

3. 모든 Pod 및 Local Storage Operator가 생성되었는지 확인하여 로컬 스토리지 설치를 확인합니다.

   1. 필요한 모든 Pod가 생성되었는지 확인합니다.

      $ oc -n openshift-local-storage get pods

      출력 예

      NAME                                      READY   STATUS    RESTARTS   AGE
      local-storage-operator-746bf599c9-vlt5t   1/1     Running   0          19m

   2. CSV(ClusterServiceVersion) YAML 매니페스트를 확인하여 openshift-local-storage 프로젝트에서 Local Storage Operator를 사용할 수 있는지 확인합니다.

      $ oc get csvs -n openshift-local-storage

      출력 예

      NAME                                         DISPLAY         VERSION               REPLACES   PHASE
      local-storage-operator.4.2.26-202003230335   Local Storage   4.2.26-202003230335              Succeeded

절차

1. 로컬 볼륨 리소스를 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.

   참고

   동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 영구 볼륨(PV)이 생성됩니다.

   예: Filesystem

   apiVersion: "local.storage.openshift.io/v1"
   kind: "LocalVolume"
   metadata:
     name: "local-disks"
     namespace: "openshift-local-storage" 1
   spec:
     nodeSelector: 2
       nodeSelectorTerms:
       - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - ip-10-0-140-183
             - ip-10-0-158-139
             - ip-10-0-164-33
     storageClassDevices:
       - storageClassName: "local-sc" 3
         volumeMode: Filesystem 4
         fsType: xfs 5
         devicePaths: 6
           - /path/to/device 7

   1

   Local Storage Operator가 설치된 네임스페이스입니다.

   2

   선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는 oc get node에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다.

   3

   영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다. Local Storage Operator가 존재하지 않는 경우 스토리지 클래스를 자동으로 생성합니다. 이 로컬 볼륨 세트를 고유하게 식별하는 스토리지 클래스를 사용해야 합니다.

   4

   로컬 볼륨의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.

   참고

   원시 블록 볼륨(volumeMode: Block)은 파일 시스템으로 포맷되지 않습니다. Pod에서 실행되는 모든 애플리케이션이 원시 블록 장치를 사용할 수 있는 경우에만 이 모드를 사용합니다.

   5

   로컬 볼륨이 처음 마운트될 때 생성되는 파일 시스템입니다.

   6

   선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.

   7

   이 값을 LocalVolume 리소스의 실제 로컬 디스크 파일 경로(예: /dev/disk/ by-id /wwn )로 바꿉니다. 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.

   참고

   RHEL KVM이 있는 IBM Z에서 OpenShift Container Platform을 실행하는 경우 VM 디스크에 일련 번호를 할당해야 합니다. 그렇지 않으면 재부팅 후 VM 디스크를 확인할 수 없습니다. virsh edit <VM > 명령을 사용하여 <serial> mydisk</serial > 정의를 추가할 수 있습니다.

   예: 블록

   apiVersion: "local.storage.openshift.io/v1"
   kind: "LocalVolume"
   metadata:
     name: "local-disks"
     namespace: "openshift-local-storage" 1
   spec:
     nodeSelector: 2
       nodeSelectorTerms:
       - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - ip-10-0-136-143
             - ip-10-0-140-255
             - ip-10-0-144-180
     storageClassDevices:
       - storageClassName: "localblock-sc" 3
         volumeMode: Block 4
         devicePaths: 5
           - /path/to/device 6

   1

   Local Storage Operator가 설치된 네임스페이스입니다.

   2

   선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는 oc get node에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다.

   3

   영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다.

   4

   로컬 볼륨의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.

   5

   선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.

   6

   이 값을 LocalVolume 리소스의 실제 로컬 디스크 파일 경로(예: dev/disk/ by-id /wwn )로 바꿉니다. 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.

   참고

   RHEL KVM이 있는 IBM Z에서 OpenShift Container Platform을 실행하는 경우 VM 디스크에 일련 번호를 할당해야 합니다. 그렇지 않으면 재부팅 후 VM 디스크를 확인할 수 없습니다. virsh edit <VM > 명령을 사용하여 <serial> mydisk</serial > 정의를 추가할 수 있습니다.

2. OpenShift Container Platform 클러스터에 로컬 볼륨 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.

   $ oc create -f <local-volume>.yaml

3. 프로비저너가 생성되었고 해당 데몬 세트가 생성되었는지 확인합니다.

   $ oc get all -n openshift-local-storage

   출력 예

   NAME                                          READY   STATUS    RESTARTS   AGE
   pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
   pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
   pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
   pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
   
   NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
   service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
   
   NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
   
   NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/local-storage-operator   1/1     1            1           14m
   
   NAME                                                DESIRED   CURRENT   READY   AGE
   replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

   필요한 데몬 세트 프로세스 및 현재 개수를 기록해 둡니다. 0의 개수는 레이블 선택기가 유효하지 않음을 나타냅니다.

4. 영구 볼륨이 생성되었는지 확인합니다.

   $ oc get pv

   출력 예

   NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
   local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
   local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
   local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

절차

1. PV를 정의합니다. PersistentVolume 오브젝트 정의로 example-pv-filesystem.yaml 또는 example-pv-block.yaml과 같은 파일을 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.

   참고

   동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 PV가 생성됩니다.

   example-pv-filesystem.yaml

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: example-pv-filesystem
   spec:
     capacity:
       storage: 100Gi
     volumeMode: Filesystem 1
     accessModes:
     - ReadWriteOnce
     persistentVolumeReclaimPolicy: Delete
     storageClassName: local-storage 2
     local:
       path: /dev/xvdf 3
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - example-node

   1

   PV의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.

   2

   PV 리소스를 생성할 때 사용할 스토리지 클래스의 이름입니다. 이 PV 세트를 고유하게 식별하는 스토리지 클래스를 사용합니다.

   3

   선택할 로컬 스토리지 장치 또는 디렉터리가 포함된 경로입니다. Filesystem volumeMode 가 있는 디렉터리만 지정할 수 있습니다.

   참고

   원시 블록 볼륨(volumeMode: block)은 파일 시스템과 함께 포맷되지 않습니다. Pod에서 실행되는 모든 애플리케이션이 원시 블록 장치를 사용할 수 있는 경우에만 이 모드를 사용합니다.

   example-pv-block.yaml

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: example-pv-block
   spec:
     capacity:
       storage: 100Gi
     volumeMode: Block 1
     accessModes:
     - ReadWriteOnce
     persistentVolumeReclaimPolicy: Delete
     storageClassName: local-storage 2
     local:
       path: /dev/xvdf 3
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - example-node

   1

   PV의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.

   2

   PV 리소스를 생성할 때 사용할 스토리지 클래스의 이름입니다. 이 PV 세트를 고유하게 식별하는 스토리지 클래스를 사용해야 합니다.

   3

   선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.

2. OpenShift Container Platform 클러스터에 PV 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.

   $ oc create -f <example-pv>.yaml

3. 로컬 PV가 생성되었는지 확인합니다.

   $ oc get pv

   출력 예

   NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS    REASON   AGE
   example-pv-filesystem   100Gi      RWO            Delete           Available                        local-storage            3m47s
   example-pv1             1Gi        RWO            Delete           Bound       local-storage/pvc1   local-storage            12h
   example-pv2             1Gi        RWO            Delete           Bound       local-storage/pvc2   local-storage            12h
   example-pv3             1Gi        RWO            Delete           Bound       local-storage/pvc3   local-storage            12h

절차

1. 해당 스토리지 클래스를 사용하여 PVC를 생성합니다.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: local-pvc-name 1
   spec:
     accessModes:
     - ReadWriteOnce
     volumeMode: Filesystem 2
     resources:
       requests:
         storage: 100Gi 3
     storageClassName: local-sc 4

   1

   PVC의 이름입니다.

   2

   PVC의 유형입니다. 기본값은 Filesystem입니다.

   3

   PVC에서 사용할 수 있는 스토리지 용량입니다.

   4

   클레임에 필요한 스토리지 클래스의 이름입니다.

2. 방금 작성한 파일을 지정하여 OpenShift Container Platform 클러스터에서 PVC를 생성합니다.

   $ oc create -f <local-pvc>.yaml

절차

1. 리소스 사양에 정의된 클레임을 포함합니다. 다음 예시는 Pod 내에서 영구 볼륨 클레임을 선언합니다.

   apiVersion: v1
   kind: Pod
   spec:
   # ...
     containers:
       volumeMounts:
       - name: local-disks 1
         mountPath: /data 2
     volumes:
     - name: local-disks
       persistentVolumeClaim:
         claimName: local-pvc-name 3
   # ...

   1

   마운트할 볼륨의 이름입니다.

   2

   볼륨이 마운트된 Pod 내부의 경로입니다. 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너가 호스트 /dev/pts 파일과 같이 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다.

   3

   사용할 기존 영구 볼륨 클레임의 이름입니다.

2. 방금 생성한 파일을 지정하여 OpenShift Container Platform 클러스터에 리소스를 생성합니다.

   $ oc create -f <local-pod>.yaml

절차

1. 웹 콘솔에서 로컬 장치를 자동으로 검색할 수 있도록 하려면 다음을 수행합니다.

   1. 관리자로 Operator → 설치된 Operator로 이동하여 로컬 볼륨 검색 탭을 클릭합니다.
   2. 로컬 볼륨 검색 만들기를 클릭합니다.

   3. 모든 또는 특정 노드에서 사용 가능한 디스크를 검색할지의 여부에 따라 모든 노드 또는 노드 선택을 선택합니다.

      참고

      모든 노드 또는 노드 선택을 사용하여 필터링하는지의 여부와 관계없이 작업자 노드만 사용할 수 있습니다.

   4. Create를 클릭합니다.

1. 노드에 사용 가능한 장치 목록을 표시하려면 다음을 수행합니다.

   1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
   2. 컴퓨팅 → 노드로 이동합니다.
   3. 열기를 원하는 노드 이름을 클릭합니다. "노드 세부 정보" 페이지가 표시됩니다.

   4. 선택한 장치 목록을 표시하려면 디스크 탭을 선택합니다.

      로컬 디스크가 추가되거나 제거되면 장치 목록이 지속적으로 업데이트됩니다. 장치를 이름, 상태, 유형, 모델, 용량 및 모드로 필터링할 수 있습니다.

2. 웹 콘솔에서 발견된 장치에 대한 로컬 볼륨을 자동으로 프로비저닝하려면 다음을 수행합니다.

   1. Operator → 설치된 Operator로 이동하고 Operator 목록에서 로컬 스토리지를 선택합니다.
   2. 로컬 볼륨 세트 → 로컬 볼륨 세트 만들기를 선택합니다.
   3. 볼륨 세트 이름과 스토리지 클래스 이름을 입력합니다.

   4. 그에 따라 필터를 적용하려면 모든 노드 또는 노드 선택을 선택합니다.

      참고

      모든 노드 또는 노드 선택을 사용하여 필터링하는지의 여부와 관계없이 작업자 노드만 사용할 수 있습니다.

   5. 로컬 볼륨 세트에 적용할 디스크 유형, 모드, 크기 및 제한을 선택하고 만들기를 클릭합니다.

      몇 분 후에 “Operator 조정됨”을 나타내는 메시지가 표시됩니다.

3. 대신 CLI에서 검색된 장치에 대한 로컬 볼륨을 프로비저닝하려면 다음을 수행합니다.

   1. 다음 예와 같이 local-volume-set.yaml과 같은 로컬 볼륨 세트를 정의하는 오브젝트 YAML 파일을 생성합니다.

      apiVersion: local.storage.openshift.io/v1alpha1
      kind: LocalVolumeSet
      metadata:
        name: example-autodetect
      spec:
        nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                    - worker-0
                    - worker-1
        storageClassName: example-storageclass 1
        volumeMode: Filesystem
        fsType: ext4
        maxDeviceCount: 10
        deviceInclusionSpec:
          deviceTypes: 2
            - disk
            - part
          deviceMechanicalProperties:
            - NonRotational
          minSize: 10G
          maxSize: 100G
          models:
            - SAMSUNG
            - Crucial_CT525MX3
          vendors:
            - ATA
            - ST2000LM

      1

      검색된 장치에서 프로비저닝된 영구 볼륨에 대해 생성된 스토리지 클래스를 결정합니다. Local Storage Operator가 존재하지 않는 경우 스토리지 클래스를 자동으로 생성합니다. 이 로컬 볼륨 세트를 고유하게 식별하는 스토리지 클래스를 사용해야 합니다.

      2

      로컬 볼륨 세트 기능을 사용할 때 Local Storage Operator는 논리 볼륨 관리(LVM) 장치 사용을 지원하지 않습니다.

   2. 로컬 볼륨 세트 오브젝트를 생성합니다.

      $ oc apply -f local-volume-set.yaml

   3. 로컬 영구 볼륨이 스토리지 클래스를 기반으로 동적으로 프로비저닝되었는지 확인합니다.

      $ oc get pv

      출력 예

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS           REASON   AGE
      local-pv-1cec77cf   100Gi      RWO            Delete           Available           example-storageclass            88m
      local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           example-storageclass            82m
      local-pv-3fa1c73    100Gi      RWO            Delete           Available           example-storageclass            48m

1. 다음 예와 같이 Pod를 정의하는 YAML 파일을 수정하고 LocalVolume 사양을 추가합니다.

     apiVersion: "local.storage.openshift.io/v1"
     kind: "LocalVolume"
     metadata:
       name: "local-disks"
       namespace: "openshift-local-storage"
     spec:
       tolerations:
         - key: localstorage 1
           operator: Equal 2
           value: "localstorage" 3
       storageClassDevices:
           - storageClassName: "localblock-sc"
             volumeMode: Block 4
             devicePaths: 5
               - /dev/xvdg

   1

   노드에 추가한 키를 지정합니다.

   2

   키/값 매개변수가 일치할 것을 요구하도록 Equal Operator를 지정합니다. Operator가 Exists인 경우 시스템은 키가 존재하는지 확인하고 값을 무시합니다. Operator가 Equal 이면 키와 값이 일치해야 합니다.

   3

   테인트된 노드의 로컬 값을 지정합니다.

   4

   볼륨 모드(파일 시스템 또는 블록)는 로컬 볼륨의 유형을 정의합니다.

   5

   선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.

2. 선택 사항: 테인트된 노드에만 로컬 영구 볼륨을 생성하려면 다음 예와 같이 YAML 파일을 수정하고 LocalVolume 사양을 추가합니다.

   spec:
     tolerations:
       - key: node-role.kubernetes.io/master
         operator: Exists

절차

1. PV에 대한 오브젝트 정의를 생성합니다.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv0001 1
   spec:
     capacity:
       storage: 5Gi 2
     accessModes:
     - ReadWriteOnce 3
     nfs: 4
       path: /tmp 5
       server: 172.17.0.2 6
     persistentVolumeReclaimPolicy: Retain 7

   1

   볼륨의 이름입니다. 이는 다양한 oc <command> pod에서 PV ID입니다.

   2

   이 볼륨에 할당된 스토리지의 용량입니다.

   3

   볼륨에 대한 액세스를 제어하는 것으로 표시되지만 실제로 레이블에 사용되며 PVC를 PV에 연결하는 데 사용됩니다. 현재는 accessModes를 기반으로 하는 액세스 규칙이 적용되지 않습니다.

   4

   사용 중인 볼륨 유형입니다(이 경우 nfs 플러그인).

   5

   NFS 서버에서 내보낸 경로입니다.

   6

   NFS 서버의 호스트 이름 또는 IP 주소입니다.

   7

   PV의 회수 정책입니다. 이는 릴리스될 때 볼륨에 발생하는 작업을 정의합니다.

   참고

   각 NFS 볼륨은 클러스터의 모든 스케줄링 가능한 노드에서 마운트할 수 있어야 합니다.

2. PV가 생성되었는지 확인합니다.

   $ oc get pv

   출력 예

   NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
   pv0001   <none>    5Gi          RWO           Available                    31s

3. 새 PV에 바인딩하는 영구 볼륨 클레임을 생성합니다.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: nfs-claim1
   spec:
     accessModes:
       - ReadWriteOnce 1
     resources:
       requests:
         storage: 5Gi 2
     volumeName: pv0001
     storageClassName: ""

   1

   액세스 모드는 보안을 적용하지 않고 PV를 PVC에 일치시키기 위한 레이블 역할을 합니다.

   2

   이 클레임에서는 5Gi 이상의 용량을 제공하는 PV를 찾습니다.

4. 영구 볼륨 클레임이 생성되었는지 확인합니다.

   $ oc get pvc

   출력 예

   NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   nfs-claim1   Bound    pv0001   5Gi        RWO                           2m

절차

1. 가상 머신 디스크를 생성합니다. VMDK(가상 머신 디스크)는 정적으로 VMware vSphere 볼륨을 프로비저닝하기 전에 수동으로 생성해야 합니다. 다음 방법 중 하나를 사용합니다.

   • vmkfstools를 사용하여 생성합니다. SSH(Secure Shell)를 통해 ESX에 액세스한 후 다음 명령을 사용하여 VMDK 볼륨을 생성합니다.

     $ vmkfstools -c <size> /vmfs/volumes/<datastore-name>/volumes/<disk-name>.vmdk

   • vmware-diskmanager를 사용하여 생성합니다.

     $ shell vmware-vdiskmanager -c -t 0 -s <size> -a lsilogic <disk-name>.vmdk

2. VMDK를 참조하는 영구 볼륨을 생성합니다. PersistentVolume 오브젝트 정의를 사용하여 pv1.yaml 파일을 생성합니다.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv1 1
   spec:
     capacity:
       storage: 1Gi 2
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     vsphereVolume: 3
       volumePath: "[datastore1] volumes/myDisk"  4
       fsType: ext4  5

   1

   볼륨의 이름입니다. 이 이름을 사용하여 영구 볼륨 클레임 또는 Pod에 의해 식별됩니다.

   2

   이 볼륨에 할당된 스토리지의 용량입니다.

   3

   vSphere 볼륨을 위해 vsphereVolume과 함께 사용되는 볼륨 유형입니다. 레이블은 vSphere VMDK 볼륨을 Pod에 마운트하는 데 사용됩니다. 볼륨의 내용은 마운트 해제 시 보존됩니다. 볼륨 유형은 VMFS 및 VSAN 데이터 저장소를 지원합니다.

   4

   사용할 기존 VMDK 볼륨입니다. vmkfstools를 사용하는 경우 이전에 설명된 대로 볼륨 정의에서 데이터 저장소의 이름을 대괄호 []로 감싸야 합니다.

   5

   마운트할 파일 시스템 유형입니다. 예를 들어, ext4, xfs 또는 기타 파일 시스템이 이에 해당합니다.

   중요

   볼륨이 포맷 및 프로비저닝된 후 fsType 매개변수 값을 변경하면 데이터가 손실되거나 Pod 오류가 발생할 수 있습니다.

3. 파일에서 PersistentVolume 오브젝트를 만듭니다.

   $ oc create -f pv1.yaml

4. 이전 단계에서 생성한 영구 볼륨 클레임에 매핑되는 영구 볼륨 클레임을 생성합니다. PersistentVolumeClaim 오브젝트 정의를 사용하여 pvc1.yaml 파일을 생성합니다.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc1 1
   spec:
     accessModes:
       - ReadWriteOnce 2
     resources:
      requests:
        storage: "1Gi" 3
     volumeName: pv1 4

   1

   영구 볼륨 오브젝트를 표시하는 고유한 이름입니다.

   2

   영구 볼륨 클레임의 액세스 모드입니다. ReadWriteOnce를 사용하면 단일 노드에서 읽기 및 쓰기 권한으로 볼륨을 마운트할 수 있습니다.

   3

   영구 볼륨 클레임의 크기입니다.

   4

   기존 영구 볼륨의 이름입니다.

5. 파일에서 PersistentVolumeClaim 오브젝트를 만듭니다.

   $ oc create -f pvc1.yaml

절차

1. Pod 오브젝트 정의를 생성하여 파일에 저장합니다.

2. 파일에 CSI 인라인 임시 볼륨을 삽입합니다.

   my-csi-app.yaml

   kind: Pod
   apiVersion: v1
   metadata:
     name: my-csi-app
   spec:
     containers:
       - name: my-frontend
         image: busybox
         volumeMounts:
         - mountPath: "/data"
           name: my-csi-inline-vol
         command: [ "sleep", "1000000" ]
     volumes: 1
       - name: my-csi-inline-vol
         csi:
           driver: inline.storage.kubernetes.io
           volumeAttributes:
             foo: bar

   1

   풀에서 사용되는 볼륨의 이름입니다.

3. 이전 단계에서 저장한 오브젝트 정의 파일을 생성합니다.

   $ oc create -f my-csi-app.yaml

절차

1. YAML 콘텐츠와 함께 oc apply 를 사용하여 Pod에서 SharedSecret CR 인스턴스를 사용하도록 지정된 서비스 계정 RBAC 권한을 부여합니다.

   참고

   현재 kubectl 및 oc 는 사용 동사를 Pod 보안에 중심으로 제한하는 특수 케이스 논리를 하드 코딩했습니다. 따라서 oc create role …​ 을 사용하여 SharedSecret CR 인스턴스를 사용하는 데 필요한 역할을 생성할 수 없습니다.

   $ oc apply -f - <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: shared-resource-my-share
     namespace: my-namespace
   rules:
     - apiGroups:
         - sharedresource.openshift.io
       resources:
         - sharedsecrets
       resourceNames:
         - my-share
       verbs:
         - use
   EOF

2. oc 명령을 사용하여 역할과 관련된 RoleBinding 을 만듭니다.

   $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

3. Pod에서 SharedSecret CR 인스턴스에 액세스합니다.

   $ oc apply -f - <<EOF
   kind: Pod
   apiVersion: v1
   metadata:
     name: my-app
     namespace: my-namespace
   spec:
     serviceAccountName: default
   
   # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume
   
       volumes:
       - name: my-csi-volume
         csi:
           readOnly: true
           driver: csi.sharedresource.openshift.io
           volumeAttributes:
             sharedSecret: my-share
   
   EOF

절차

1. 클러스터의 네임스페이스에서 공유할 구성 맵에 대해 SharedConfigMap CR 인스턴스를 생성합니다.

   $ oc apply -f - <<EOF
   apiVersion: sharedresource.openshift.io/v1alpha1
   kind: SharedConfigMap
   metadata:
     name: my-share
   spec:
     configMapRef:
       name: <name of configmap>
       namespace: <namespace of configmap>
   EOF

절차

1. oc apply with YAML 콘텐츠를 사용하여 Pod에서 SharedConfigMap CR 인스턴스를 사용할 수 있도록 지정된 서비스 계정 RBAC 권한을 부여합니다.

   참고

   현재 kubectl 및 oc 는 사용 동사를 Pod 보안에 중심으로 제한하는 특수 케이스 논리를 하드 코딩했습니다. 따라서 oc create role …​ 을 사용하여 SharedConfigMap CR 인스턴스를 사용하는 데 필요한 역할을 생성할 수 없습니다.

   $ oc apply -f - <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: shared-resource-my-share
     namespace: my-namespace
   rules:
     - apiGroups:
         - sharedresource.openshift.io
       resources:
         - sharedconfigmaps
       resourceNames:
         - my-share
       verbs:
         - use
   EOF

2. oc 명령을 사용하여 역할과 관련된 RoleBinding 을 만듭니다.

   oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

3. Pod에서 SharedConfigMap CR 인스턴스에 액세스합니다.

   $ oc apply -f - <<EOF
   kind: Pod
   apiVersion: v1
   metadata:
     name: my-app
     namespace: my-namespace
   spec:
     serviceAccountName: default
   
   # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume
   
       volumes:
       - name: my-csi-volume
         csi:
           readOnly: true
           driver: csi.sharedresource.openshift.io
           volumeAttributes:
             sharedConfigMap: my-share
   
   EOF

1. 다음 YAML로 설명된 VolumeSnapshotClass 오브젝트로 파일을 생성합니다.

   volumesnapshotclass.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: csi-hostpath-snap
   driver: hostpath.csi.k8s.io 1
   deletionPolicy: Delete

   1

   이 VolumeSnapshotClass 오브젝트의 스냅샷을 생성하는 데 사용되는 CSI 드라이버의 이름입니다. 이름은 스냅샷을 수행 중인 PVC를 담당하는 스토리지 클래스의 Provisioner 필드와 동일해야 합니다.

   참고

   영구 스토리지를 구성하는 데 사용한 드라이버에 따라 추가 매개변수가 필요할 수 있습니다. 기존 VolumeSnapshotClass 오브젝트를 사용할 수도 있습니다.

2. 다음 명령을 입력하여 이전 단계에서 저장한 오브젝트를 생성합니다.

   $ oc create -f volumesnapshotclass.yaml

3. VolumeSnapshot 오브젝트를 생성합니다.

   volumesnapshot-dynamic.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: mysnap
   spec:
     volumeSnapshotClassName: csi-hostpath-snap 1
     source:
       persistentVolumeClaimName: myclaim 2

   1

   볼륨 스냅샷의 특정 클래스에 대한 요청입니다. volumeSnapshotClassName 설정이 없으며 기본 볼륨 스냅샷 클래스가 있는 경우 기본 볼륨 스냅샷 클래스 이름을 사용하여 스냅샷이 생성됩니다. 그러나 필드가 없으며 기본 볼륨 스냅샷 클래스가 없는 경우에는 스냅샷이 생성되지 않습니다.

   2

   영구 볼륨에 바인딩된 PersistentVolumeClaim 오브젝트의 이름입니다. 이 명령은 스냅샷을 생성할 대상을 정의합니다. 스냅샷을 동적으로 프로비저닝하는 데 필요합니다.

4. 다음 명령을 입력하여 이전 단계에서 저장한 오브젝트를 생성합니다.

   $ oc create -f volumesnapshot-dynamic.yaml

1. 위에서 설명한 볼륨 스냅샷 클래스를 정의하는 것 외에도 volumeSnapshotContentName 매개변수 값을 스냅샷의 소스로 제공해야 합니다.

   volumesnapshot-manual.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: snapshot-demo
   spec:
     source:
       volumeSnapshotContentName: mycontent 1

   1

   사전 프로비저닝된 스냅샷에는 volumeSnapshotContentName 매개변수가 필요합니다.

2. 다음 명령을 입력하여 이전 단계에서 저장한 오브젝트를 생성합니다.

   $ oc create -f volumesnapshot-manual.yaml

1. 생성된 볼륨 스냅샷에 대한 세부 정보를 표시하려면 다음 명령을 입력합니다.

   $ oc describe volumesnapshot mysnap

   다음 예시는 mysnap 볼륨 스냅샷에 대한 세부 정보를 표시합니다.

   volumesnapshot.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: mysnap
   spec:
     source:
       persistentVolumeClaimName: myclaim
     volumeSnapshotClassName: csi-hostpath-snap
   status:
     boundVolumeSnapshotContentName: snapcontent-1af4989e-a365-4286-96f8-d5dcd65d78d6 1
     creationTime: "2020-01-29T12:24:30Z" 2
     readyToUse: true 3
     restoreSize: 500Mi

   1

   컨트롤러가 생성한 실제 스토리지 콘텐츠의 포인터입니다.

   2

   스냅샷이 생성된 시간입니다. 스냅샷에는 이 표시된 시점에서 사용 가능한 볼륨 내용이 포함되어 있습니다.

   3

   값을 true로 설정하면 스냅샷을 사용하여 새 PVC로 복원할 수 있습니다.
   값을 false로 설정하면 스냅샷이 생성됩니다. 하지만 스토리지 백엔드는 스냅샷을 사용할 수 있도록 추가 작업을 수행하여 새 볼륨으로 복원해야 합니다. 예를 들어, Amazon Elastic Block Store 데이터를 다른 저렴한 위치로 이동할 수 있으며, 이 작업에는 몇 분이 걸릴 수 있습니다.

2. 볼륨 스냅샷이 생성되었는지 확인하려면 다음 명령을 입력합니다.

   $ oc get volumesnapshotcontent

   실제 컨텐츠에 대한 포인터가 표시됩니다. boundVolumeSnapshotContentName 필드가 입력된 경우 VolumeSnapshotContent 오브젝트가 존재하고 스냅샷이 생성된 것입니다.

3. 스냅샷이 준비되었는지 확인하려면 VolumeSnapshot 오브젝트에 readyToUse: true가 있는지 확인합니다.

절차

1. 다음 예와 같이 VolumeSnapshotClass 오브젝트에 필요한 삭제 정책을 지정합니다.

   volumesnapshotclass.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: csi-hostpath-snap
   driver: hostpath.csi.k8s.io
   deletionPolicy: Delete 1

   1

   볼륨 스냅샷을 삭제할 때 Delete 값이 설정되면 VolumeSnapshotContent 오브젝트와 함께 기본 스냅샷이 삭제됩니다. Retain 값이 설정된 경우 기본 스냅샷 및 VolumeSnapshotContent 오브젝트다 모두 유지됩니다.
   Retain 값이 설정되고 해당 VolumeSnapshotContent 오브젝트를 삭제하지 않고 VolumeSnapshot 오브젝트가 삭제되면 해당 콘텐츠는 그대로 유지됩니다. 스냅샷 자체는 스토리지 백엔드에서도 유지됩니다.

2. 다음 명령을 입력하여 볼륨 스냅샷을 삭제합니다.

   $ oc delete volumesnapshot <volumesnapshot_name>

   출력 예

   volumesnapshot.snapshot.storage.k8s.io "mysnapshot" deleted

3. 삭제 정책이 Retain으로 설정된 경우 다음 명령을 입력하여 볼륨 스냅샷 콘텐츠를 삭제합니다.

   $ oc delete volumesnapshotcontent <volumesnapshotcontent_name>

4. 선택 사항: VolumeSnapshot 오브젝트가 성공적으로 삭제되지 않으면 삭제 작업이 계속될 수 있도록 다음 명령을 입력하여 남은 리소스의 종료자를 제거합니다.

   중요

   VolumeSnapshot 오브젝트에 대한 영구 볼륨 클레임 또는 볼륨 스냅샷 콘텐츠에서 기존 참조가 없음을 확신할 수 있는 경우에만 종료자를 제거하십시오. --force 옵션을 사용하면 모든 종료자가 제거될 때까지 삭제 작업에서 스냅샷 오브젝트를 삭제하지 않습니다.

   $ oc patch -n $PROJECT volumesnapshot/$NAME --type=merge -p '{"metadata": {"finalizers":null}}'

   출력 예

   volumesnapshotclass.snapshot.storage.k8s.io "csi-ocs-rbd-snapclass" deleted

   종료자가 제거되고 볼륨 스냅샷이 삭제됩니다.

절차

1. 다음과 같이 PVC에서 VolumeSnapshot 데이터 소스를 지정합니다.

   pvc-restore.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: myclaim-restore
   spec:
     storageClassName: csi-hostpath-sc
     dataSource:
       name: mysnap 1
       kind: VolumeSnapshot 2
       apiGroup: snapshot.storage.k8s.io 3
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi

   1

   소스로 사용할 스냅샷을 나타내는 VolumeSnapshot 오브젝트의 이름입니다.

   2

   VolumeSnapshot 값으로 설정해야 합니다.

   3

   snapshot.storage.k8s.io 값으로 설정해야 합니다.

2. 다음 명령을 입력하여 PVC를 생성합니다.

   $ oc create -f pvc-restore.yaml

3. 다음 명령을 입력하여 복원된 PVC가 생성되었는지 확인합니다.

   $ oc get pvc

   myclaim-restore와 같은 새 PVC가 표시됩니다.

1. 다음 YAML로 설명된 PersistentVolumeClaim 오브젝트를 사용하여 파일을 생성하고 저장합니다.

   pvc-clone.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-1-clone
     namespace: mynamespace
   spec:
     storageClassName: csi-cloning 1
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 5Gi
     dataSource:
       kind: PersistentVolumeClaim
       name: pvc-1

   1

   스토리지 백엔드를 프로비저닝하는 스토리지 클래스의 이름입니다. 기본 스토리지 클래스를 사용할 수 있으며 storageClassName은 사양에서 생략할 수 있습니다.

2. 다음 명령을 실행하여 이전 단계에서 저장한 오브젝트를 생성합니다.

   $ oc create -f pvc-clone.yaml

   새 PVC pvc-1-clone이 생성됩니다.

3. 볼륨 복제가 생성되어 다음 명령을 실행하여 준비되었는지 확인합니다.

   $ oc get pvc pvc-1-clone

   pvc-1-clone에 Bound로 표시됩니다.

   이제 새로 복제된 PVC를 사용하여 Pod를 구성할 준비가 되었습니다.

4. YAML로 설명된 Pod 오브젝트로 파일을 생성하고 저장합니다. 예를 들면 다음과 같습니다.

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

   1

   CSI 볼륨 복제 작업 중에 생성된 복제 PVC입니다.

   생성된 Pod 오브젝트가 원래 dataSource PVC와 독립적으로 복제된 PVC를 사용, 복제, 삭제하거나 그 스냅샷을 생성할 준비가 되었습니다.

1. 웹 콘솔에 로그인합니다.

2. AWS EFS CSI Operator를 설치합니다.

   1. Operators → OperatorHub를 클릭합니다.
   2. 필터 상자에 AWS EFS CSI를 입력하여 AWS EFS CSI Operator를 찾습니다.

   3. AWS EFS CSI Driver Operator 버튼을 클릭합니다.

      중요

      AWS EFS Operator가 아닌 AWS EFS CSI Driver Operator를 선택해야 합니다. AWS EFS Operator는 커뮤니티 Operator이며 Red Hat에서 지원하지 않습니다.

   4. AWS EFS CSI Driver Operator 페이지에서 설치를 클릭합니다.

   5. Operator 설치 페이지에서 다음을 확인합니다.

      • 클러스터의 모든 네임스페이스(기본값)가 선택됩니다.
      • 설치된 네임스페이스는 openshift-cluster-csi-drivers로 설정됩니다.

   6. 설치를 클릭합니다.

      설치가 완료되면 AWS EFS CSI Operator가 웹 콘솔의 설치된 Operators 섹션에 나열됩니다.

3. AWS STS(Security Token Service)가 있는 AWS EFS를 사용하는 경우 STS를 사용하여 AWS EFS CSI 드라이버를 구성해야 합니다. 자세한 내용은 "AWS EFS CSI 드라이버 구성"을 참조하십시오.

4. AWS EFS CSI 드라이버를 설치합니다.

   1. 관리 → CustomResourceDefinitions → ClusterCSIDriver를 클릭합니다.
   2. Instances 탭에서 Create ClusterCSIDriver를 클릭합니다.

   3. 다음 YAML 파일을 사용합니다.

      apiVersion: operator.openshift.io/v1
      kind: ClusterCSIDriver
      metadata:
          name: efs.csi.aws.com
      spec:
        managementState: Managed

   4. 생성을 클릭합니다.

   5. 다음 조건이 "true" 상태로 변경될 때까지 기다립니다.

      • AWSEFSDriverCredentialsRequestControllerAvailable
      • AWSEFSDriverNodeServiceControllerAvailable
      • AWSEFSDriverControllerServiceControllerAvailable

1. STS를 사용하여 클러스터를 설치하는 데 사용한 OpenShift Container Platform 릴리스 이미지에서 CCO 유틸리티(ccoctl) 바이너리를 추출합니다. 자세한 내용은 "Cloud Credential Operator 유틸리티 구성"을 참조하십시오.

2. 다음 예에 표시된 것처럼 EFS CredentialsRequest YAML 파일을 생성하고 저장한 다음 credrequests 디렉터리에 배치합니다.

   예제

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: openshift-aws-efs-csi-driver
     namespace: openshift-cloud-credential-operator
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AWSProviderSpec
       statementEntries:
       - action:
         - elasticfilesystem:*
         effect: Allow
         resource: '*'
     secretRef:
       name: aws-efs-cloud-credentials
       namespace: openshift-cluster-csi-drivers
     serviceAccountNames:
     - aws-efs-csi-driver-operator
     - aws-efs-csi-driver-controller-sa

3. ccoctl 툴을 실행하여 AWS에서 새 IAM 역할을 생성하고 로컬 파일 시스템(<path_to_ccoctl_output_dir>/manifests/openshift-cluster-csi-drivers-aws-credentials-credentials.yaml )에서 YAML 파일을 생성합니다.

   $ ccoctl aws create-iam-roles --name=<name> --region=<aws_region> --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com

   • name=<name >은 추적을 위해 생성된 클라우드 리소스에 태그하는 데 사용되는 이름입니다.
   • region=<aws_region& gt;은 클라우드 리소스가 생성되는 AWS 리전입니다.
   • dir=<path_to_directory_with_list_of_credentials_requests>/credrequests 는 이전 단계에서 EFS CredentialsRequest 파일을 포함하는 디렉터리입니다.

   • <aws_account_id& gt;는 AWS 계정 ID입니다.

     예제

     $ ccoctl aws create-iam-roles --name my-aws-efs --credentials-requests-dir credrequests --identity-provider-arn arn:aws:iam::123456789012:oidc-provider/my-aws-efs-oidc.s3.us-east-2.amazonaws.com

     출력 예

     2022/03/21 06:24:44 Role arn:aws:iam::123456789012:role/my-aws-efs -openshift-cluster-csi-drivers-aws-efs-cloud- created
     2022/03/21 06:24:44 Saved credentials configuration to: /manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml
     2022/03/21 06:24:45 Updated Role policy for Role my-aws-efs-openshift-cluster-csi-drivers-aws-efs-cloud-

4. AWS EFS 클라우드 인증 정보 및 시크릿을 생성합니다.

   $ oc create -f <path_to_ccoctl_output_dir>/manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml

   예제

   $ oc create -f /manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml

   출력 예

   secret/aws-efs-cloud-credentials created

1. AWS 콘솔에서 https://console.aws.amazon.com/efs을 엽니다.

2. 파일 시스템 생성을 클릭합니다.

   • 파일 시스템의 이름을 입력합니다.
   • VPC(Virtual Private Cloud) 의 경우 OpenShift Container Platform의 VPC(가상 프라이빗 클라우드)를 선택합니다.
   • 다른 모든 선택 사항에 대해 기본 설정을 수락합니다.

3. 볼륨 및 마운트 대상이 완전히 생성될 때까지 기다립니다.

   1. https://console.aws.amazon.com/efs#/file-systems로 이동합니다.
   2. 볼륨을 클릭하고 네트워크 탭에서 모든 마운트 대상이 사용 가능하게 될 때까지 기다립니다(-1-2분).
4. 네트워크 탭에서 Security Group ID(다음 단계에서 필요함)를 복사합니다.
5. https://console.aws.amazon.com/ec2/v2/home#SecurityGroups로 이동하여 EFS 볼륨에서 사용하는 보안 그룹을 찾습니다.

6. 인바운드 규칙 탭에서 인바운드 규칙 편집을 클릭한 다음 다음 설정으로 새 규칙을 추가하여 OpenShift Container Platform 노드에서 EFS 볼륨에 액세스할 수 있도록 합니다.

   • 유형: NFS
   • 프로토콜: TCP
   • 포트 범위: 2049

   • 출처: 노드의 사용자 정의/IP 주소 범위 (예: "10.0.0.0/16")

     이 단계에서는 OpenShift Container Platform에서 클러스터의 NFS 포트를 사용할 수 있습니다.

7. 규칙을 저장합니다.

1. 웹 콘솔에 로그인합니다.
2. AWS EFS PV를 사용하는 모든 애플리케이션을 중지합니다.

3. 모든 AWS EFS PV를 삭제합니다.

   1. 스토리지 → 영구 볼륨 클레임을 클릭합니다.
   2. AWS EFS CSI Driver Operator에서 사용 중인 각 PVC를 선택하고 PVC 오른쪽에 있는 드롭다운 메뉴를 클릭한 다음 영구 볼륨 클레임 삭제를 클릭합니다.

4. AWS EFS CSI 드라이버를 설치 제거합니다.

   참고

   Operator를 설치 제거하려면 CSI 드라이버를 먼저 제거해야 합니다.

   1. 관리 → CustomResourceDefinitions → ClusterCSIDriver를 클릭합니다.
   2. 인스턴스 탭에서 efs.csi.aws.com의 맨 왼쪽에 있는 드롭다운 메뉴를 클릭한 다음 ClusterCSIDriver 삭제를 클릭합니다.
   3. 메시지가 표시되면 삭제를 클릭합니다.

5. AWS EFS CSI Operator를 설치 제거합니다.

   1. Operators → 설치된 Operators를 클릭합니다.
   2. 설치된 Operators 페이지에서 스크롤하거나 AWS EFS CSI를 이름으로 검색 상자에 입력하여 Operator를 찾은 다음 클릭합니다.
   3. 설치된 Operator > Operator 세부 정보 페이지 오른쪽 상단에서 작업 → Operator 설치 제거를 클릭합니다.

   4. Operator 설치 제거 창이 표시되면 제거 버튼을 클릭하여 네임스페이스에서 Operator를 제거합니다. 클러스터에 Operator가 배포한 애플리케이션을 수동으로 정리해야 합니다.

      설치 제거 후 AWS EFS CSI Driver Operator는 더 이상 웹 콘솔의 설치된 Operator 섹션에 나열되지 않습니다.

1. 다음과 유사한 YAML 파일을 사용하여 스토리지 계정 유형을 지정하는 스토리지 클래스를 생성합니다.

   $ oc create -f - << EOF
   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <storage-class> 1
   provisioner: disk.csi.azure.com
   parameters:
     skuName: <storage-class-account-type> 2
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   EOF

   1

   스토리지 클래스 이름입니다.

   2

   스토리지 계정 유형. 이는 Azure 스토리지 계정 SKU 계층에 해당합니다. 즉, Premium_LRS, Premium_LRS,StandardSSD_LRS,UltraSSD_LRS,Premium_ZRS,StandardSSD_ZRS.

2. 스토리지 클래스를 나열하여 스토리지 클래스가 생성되었는지 확인합니다.

   $ oc get storageclass

   출력 예

   $ oc get storageclass
   NAME                    PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   azurefile-csi           file.csi.azure.com   Delete          Immediate              true                   68m
   managed-csi (default)   disk.csi.azure.com   Delete          WaitForFirstConsumer   true                   68m
   sc-prem-zrs             disk.csi.azure.com   Delete          WaitForFirstConsumer   true                   4m25s 1

   1

   스토리지 계정 유형의 새 스토리지 클래스입니다.

1. Cloud KMS 키를 사용하여 스토리지 클래스를 생성합니다. 다음 예시에서는 암호화된 볼륨의 동적 프로비저닝을 활성화합니다.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: csi-gce-pd-cmek
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: "WaitForFirstConsumer"
   allowVolumeExpansion: true
   parameters:
     type: pd-standard
     disk-encryption-kms-key: projects/<key-project-id>/locations/<location>/keyRings/<key-ring>/cryptoKeys/<key> 1

   1

   이 필드는 새 디스크를 암호화하는 데 사용할 키의 리소스 식별자여야 합니다. 값은 대소문자를 구분합니다. 키 ID 값을 제공하는 방법에 대한 자세한 내용은 리소스의 ID 검색 및 Cloud KMS 리소스 ID 가져오기를 참조하십시오.

   참고

   disk-encryption-✓s-key 매개변수를 기존 스토리지 클래스에 추가할 수 없습니다. 그러나 스토리지 클래스를 삭제하고 동일한 이름과 다른 매개변수 세트로 다시 생성할 수 있습니다. 이렇게 하는 경우 기존 클래스의 프로비저너가 pd.csi.storage.gke.io여야 합니다.

2. oc 명령을 사용하여 OpenShift Container Platform 클러스터에 스토리지 클래스를 배포합니다.

   $ oc describe storageclass csi-gce-pd-cmek

   출력 예

   Name:                  csi-gce-pd-cmek
   IsDefaultClass:        No
   Annotations:           None
   Provisioner:           pd.csi.storage.gke.io
   Parameters:            disk-encryption-kms-key=projects/key-project-id/locations/location/keyRings/ring-name/cryptoKeys/key-name,type=pd-standard
   AllowVolumeExpansion:  true
   MountOptions:          none
   ReclaimPolicy:         Delete
   VolumeBindingMode:     WaitForFirstConsumer
   Events:                none

3. 이전 단계에서 생성한 스토리지 클래스 오브젝트의 이름과 일치하는 pvc.yaml 파일을 생성합니다.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: podpvc
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: csi-gce-pd-cmek
     resources:
       requests:
         storage: 6Gi

   참고

   새 스토리지 클래스를 기본값으로 표시한 경우 storageClassName 필드를 생략할 수 있습니다.

4. 클러스터에 PVC를 적용합니다.

   $ oc apply -f pvc.yaml

5. PVC 상태를 가져온 후 새로 프로비저닝된 PV에 바인딩되었는지 확인합니다.

   $ oc get pvc

   출력 예

   NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
   podpvc    Bound     pvc-e36abf50-84f3-11e8-8538-42010a800002   10Gi       RWO            csi-gce-pd-cmek  9s

   참고

   스토리지 클래스에 WaitForFirstConsumer로 설정된 volumeBindingMode 필드가 있는 경우 이를 확인하기 전에 PVC를 사용하도록 Pod를 생성해야 합니다.

1. 스토리지 클래스를 나열합니다.

   $ oc get storageclass

   출력 예

   NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   standard(default)      cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   46h
   standard-csi           kubernetes.io/cinder       Delete          WaitForFirstConsumer   true                   46h

2. 기본 StorageClass에 대해 주석 storageclass.kubernetes.io/is-default-class의 값을 false로 변경합니다.

   $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'

3. 주석을 storageclass.kubernetes.io/is-default-class=true로 추가하거나 수정하여 다른 스토리지 클래스를 기본값으로 설정합니다.

   $ oc patch storageclass standard-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'

4. PVC가 기본적으로 CSI 스토리지 클래스를 참조하는지 확인합니다.

   $ oc get storageclass

   출력 예

   NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   standard               kubernetes.io/cinder       Delete          WaitForFirstConsumer   true                   46h
   standard-csi(default)  cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   46h

5. 선택 사항: 스토리지 클래스를 지정하지 않고도 새 PVC를 정의할 수 있습니다.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: cinder-claim
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi

   특정 스토리지 클래스를 지정하지 않는 PVC는 기본 스토리지 클래스를 사용하여 자동으로 프로비저닝됩니다.

6. 선택 사항: 새 파일을 구성한 후 클러스터에서 파일을 생성합니다.

   $ oc create -f cinder-claim.yaml

1. OpenShift Container Platform 콘솔에서 스토리지 → 영구 볼륨 클레임을 클릭합니다.
2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.

3. 결과 페이지에 필요한 옵션을 정의합니다.

   1. 적절한 스토리지 클래스를 선택합니다.
   2. 스토리지 클레임의 고유한 이름을 입력합니다.

   3. 생성 중인 PVC에 대한 읽기 및 쓰기 권한을 지정하려면 액세스 모드를 선택합니다.

      중요

      이 PVC를 클러스터의 여러 노드의 여러 Pod에 마운트하도록 하는 PV(영구 볼륨)를 사용하려면 RWX를 사용합니다.

4. 스토리지 클레임의 크기를 정의합니다.
5. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.

1. 다음 YAML로 설명된 PersistentVolumeClaim 오브젝트를 사용하여 파일을 생성하고 저장합니다.

   pvc-manila.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-manila
   spec:
     accessModes: 1
       - ReadWriteMany
     resources:
       requests:
         storage: 10Gi
     storageClassName: csi-manila-gold 2

   1

   이 PVC를 클러스터의 여러 노드의 여러 Pod에 마운트하도록 하는 PV(영구 볼륨)를 사용하려면 RWX를 사용합니다.

   2

   스토리지 백엔드를 프로비저닝하는 스토리지 클래스의 이름입니다. Manila 스토리지 클래스는 Operator에 의해 프로비저닝되며 csi-manila- 접두사가 적용됩니다.

2. 다음 명령을 실행하여 이전 단계에서 저장한 오브젝트를 생성합니다.

   $ oc create -f pvc-manila.yaml

   새 PVC가 생성됩니다.

3. 볼륨이 생성되고 준비되었는지 확인하려면 다음 명령을 실행합니다.

   $ oc get pvc pvc-manila

   pvc-manila에 Bound가 표시됩니다.

절차

1. 타사 vSphere CSI 드라이버(VMware vSphere Container Storage 플러그인) 배포 및 데몬 세트 오브젝트를 삭제합니다.
2. 타사 vSphere CSI 드라이버를 사용하여 이전에 설치된 configmap 및 secret 오브젝트를 삭제합니다.

3. 타사 vSphere CSI 드라이버 CSIDriver 오브젝트를 삭제합니다.

   ~ $ oc delete CSIDriver csi.vsphere.vmware.com

   csidriver.storage.k8s.io "csi.vsphere.vmware.com" deleted