File Storage for Classic 설정

파일 스토리지 유형

프로비저닝할 File Storage for Classic의 유형을 선택하십시오.

브론즈, 실버 및 골드 스토리지 클래스

이러한 스토리지 클래스는 Endurance 스토리지를 프로비저닝합니다. Endurance 스토리지를 사용하면 사전 정의된 IOPS 티어에서 기가바이트 단위로 스토리지의 크기를 선택할 수 있습니다.

사용자 정의 스토리지 클래스

이 스토리지 클래스는 성능 스토리지를 프로비저닝합니다. 성능 스토리지를 사용하면 IOPS 및 스토리지의 크기에 대한 추가적인 제어가 가능합니다.

IOPS

File Storage for Classic의 크기와 IOPS를 선택하십시오. IOPS의 크기와 수는 스토리지의 속도에 대한 지표의 역할을 하는 IOPS(Input/output Operations Per Second) 수의 총계를 정의합니다. 스토리지에 총 IOPS가 많을 수록 읽기/쓰기 오퍼레이션의 처리 속도가 빨라집니다.

브론즈, 실버 및 골드 스토리지 클래스

이러한 스토리지 클래스는 기가바이트당 고정된 수의 IOPS가 제공되며 SSD 하드 디스크에 프로비저닝됩니다. IOPS 수의 총계는 선택하는 스토리지의 크기에 따라 다릅니다. 허용된 크기 범위 내에서 GB 단위의 정수를 선택할 수 있습니다(예: 20Gi, 256Gi 또는 11854Gi). IOPS 수의 총계를 판별하려면 IOPS를 선택된 크기와 곱해야 합니다. 예를 들어, GB당 4 IOPS가 제공되는 실버 스토리지 클래스에서 1000Gi File Storage for Classic 크기를 선택하는 경우에는 스토리지는 총 4000 IOPS입니다.

사용자 정의 스토리지 클래스

이 스토리지 클래스를 선택하면 원하는 IOPS와 크기에 대해 추가적인 제어가 가능합니다. 크기의 경우, 허용된 크기 범위 내에서 GB 단위의 정수를 선택할 수 있습니다. 사용자가 선택하는 크기에 따라 사용 가능한 IOPS 범위가 결정됩니다. 지정된 범위 내에 있는 100의 배수인 IOPS를 선택할 수 있습니다. 선택하는 IOPS는 정적이며 스토리지의 크기에 따라 스케일링되지 않습니다. 예를 들어, 100 IOPS와 함께 40Gi를 선택하면 총 IOPS는 100을 유지합니다.

IOPS 대 기가바이트 비율은 사용자를 위해 프로비저닝되는 하드 디스크의 유형도 결정합니다. 예를 들어, 100 IOPS의 500Gi를 보유 중이면 IOPS 대 기가바이트 비율은 0.2입니다. 비율이 0.3 이하인 스토리지는 SATA 하드 디스크에서 프로비저닝됩니다. 비율이 0.3을 초과하는 스토리지는 SSD 하드 디스크에서 프로비저닝됩니다.

재확보 정책

클러스터 또는 지속적 볼륨 청구(PVC)가 삭제된 후에 데이터를 보존하고자 하는지를 선택하십시오.

• 데이터를 보존하려면 retain 스토리지 클래스를 선택하십시오. PVC를 삭제하면 PVC만 삭제됩니다. PV, IBM Cloud 인프라 계정의 실제 스토리지 디바이스 및 데이터는 여전히 존재합니다. 스토리지를 재확보하고 클러스터에서 이를 다시 사용하려면 PV를 제거한 후 기존 File Storage for Classic 사용 단계를 수행해야 합니다.
• PVC를 삭제할 때 PV, 데이터 및 실제 File Storage for Classic 디바이스를 삭제하려면 retain 없이 스토리지 클래스를 선택하십시오.

비용 청구 유형

시간별 또는 월별을 선택하십시오. 자세한 정보는 가격 책정 을 검토하십시오.

기본적으로 모든 File Storage for Classic 디바이스는 시간별 비용 청구 유형으로 프로비저닝됩니다.

월별 비용 청구 유형을 선택하는 경우, 지속적 스토리지를 제거하면 짧은 기간만 사용해도 이에 대해 여전히 월별 비용을 지불하게 됩니다.

기존 스토리지 준비

기존 스토리지를 앱에 마운트하려면 우선 PV에 대한 모든 필수 정보를 검색하고 클러스터에서 액세스 가능하도록 스토리지를 준비해야 합니다.

retain 스토리지 클래스로 프로비저닝된 스토리지의 경우.

retain 스토리지 클래스로 프로비저닝한 스토리지가 있으면 PVC를 제거할 때 PV 및 실제 스토리지 디바이스가 자동으로 제거되지 않습니다. 클러스터의 스토리지를 재사용하려면 우선 나머지 PV를 제거해야 합니다.

프로비저닝된 클러스터와는 다른 클러스터에 있는 기존 스토리지를 사용하려면 클러스터 외부에서 작성된 스토리지의 단계에 따라 스토리지를 작업자 노드의 서브넷에 추가하십시오.

1. 기존 PV를 나열하십시오.

   kubectl get pv
   

   지속적 스토리지에 속하는 PV를 찾으십시오. PV는 released 상태입니다.

2. PV의 세부사항을 가져오십시오.

   kubectl describe pv <pv_name>
   

3. CapacityGb, storageClass, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, server 및 path를 기록해 두십시오.

4. PV를 제거하십시오.

   kubectl delete pv <pv_name>
   

5. PV가 제거되었는지 확인하십시오.

   kubectl get pv
   

클러스터 외부에서 프로비저닝된 영구 스토리지의 경우

이전에 프로비저닝했지만 이전에 클러스터에서 사용된 적이 없는 기존 스토리지를 사용하려면, 작업자 노드와 동일한 서브넷에서 해당 스토리지가 사용 가능하도록 해야 합니다.

1. IBM Cloud 인프라 포털 에서 ‘저장소’를 클릭합니다.
2. 조치 메뉴에서 File Storage for Classic를 클릭하고 호스트에 권한 부여를 선택하십시오.
3. 서브넷을 선택하십시오.
4. 드롭 다운 목록에서 작업자 노드가 연결된 사설 VLAN 서브넷을 선택하십시오. 작업자 노드의 서브넷을 찾으려면 ibmcloud ks worker ls --cluster <cluster_name>을 실행하고 작업자 노드의 Private IP를 드롭 다운 목록에서 찾은 서브넷과 비교하십시오.
5. 제출을 클릭하십시오.
6. File Storage for Classic의 이름을 클릭하십시오.
7. Mount Point, size 및 Location 필드를 기록해 두십시오. Mount Point 필드는 <nfs_server>:<file_storage_path>로 표시됩니다.

영구 볼륨 및 영구 볼륨 클레임 생성

1. PV에 대한 스토리지 구성 파일을 작성하십시오. 이전에 검색한 값을 포함하십시오.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
    name: mypv
    labels:
       failure-domain.beta.kubernetes.io/region: <region>
       failure-domain.beta.kubernetes.io/zone: <zone>
   spec:
    capacity:
      storage: "<size>"
    accessModes:
      - ReadWriteMany
    nfs:
      server: "<nfs_server>"
      path: "<file_storage_path>"
   

   name

   작성할 PV 오브젝트의 이름을 입력하십시오.

   labels

   이전에 검색한 지역 및 구역을 입력하십시오. 동일한 지역 및 구역에 작업자 노드가 하나 이상 있어야 합니다.

   storage

   이전에 검색한 기존 NFS 파일 공유의 스토리지 크기를 입력하십시오. 스토리지 크기는 기가바이트(예: 20Gi(20GB) 또는 1000Gi(1TB))로 기록되어야 하며 그 크기는 기존 파일 공유의 크기와 일치해야 합니다.

   accessMode

   다음 옵션 중 하나를 지정하십시오.

   • ReadWriteMany: PVC는 다중 팟(pod)으로 마운트할 수 있습니다. 모든 팟(Pod)은 볼륨에서 읽고 쓸 수 있습니다.
   • ReadOnlyMany: PVC는 다중 팟(pod)으로 마운트할 수 있습니다. 모든 팟(Pod)에는 읽기 전용 액세스 권한이 있습니다.
   • ReadWriteOnce: PVC는 하나의 팟(pod)으로만 마운트할 수 있습니다. 이 팟(Pod)은 볼륨에서 읽고 쓸 수 있습니다.

   server

   이전에 검색한 NFS 파일 공유 서버 ID를 입력하십시오.

   path

   이전에 검색한 기존 NFS 파일 공유에 대한 경로를 입력하십시오.

2. 클러스터에 PV를 작성하십시오.

   kubectl apply -f mypv.yaml
   

3. PV가 작성되었는지 확인하십시오.

   kubectl get pv
   

4. 다른 구성 파일을 작성하여 PVC를 작성하십시오. PVC가 이전에 작성한 PV와 일치하려면 storage 및 accessMode에 대해 동일한 값을 선택해야 합니다. storage-class 필드는 빈 문자열이어야 합니다. 이 필드 중 하나라도 PV와 일치하지 않으면, 새로운 PV와 새로운 물리적 스토리지 인스턴스가 동적으로 프로비저닝됩니다.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: mypvc
   spec:
     accessModes:
      - ReadWriteMany
     resources:
       requests:
         storage: "<size>"
     storageClassName: ""
   

5. PVC를 작성하십시오.

   kubectl apply -f mypvc.yaml
   

6. PVC가 작성되고 PV에 바인딩되는지 확인하십시오.

   kubectl describe pvc mypvc
   

   출력 예

   Name: mypvc
   Namespace: default
   StorageClass:    ""
   Status: Bound
   Volume: pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   Labels: <none>
   Capacity: 20Gi
   Access Modes: RWX
   Events:
       FirstSeen LastSeen Count From        SubObjectPath Type Reason Message
       --------- -------- ----- ----        ------------- -------- ------ -------
       3m 3m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal Provisioning External provisioner is provisioning volume for claim "default/my-persistent-volume-claim"
       3m 1m     10 {persistentvolume-controller } Normal ExternalProvisioning can't find provisioner "ibm.io/ibmc-file", expecting that a volume for the claim is provisioned either manually or via external software
       1m 1m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   

PV를 작성하여 PVC에 바인딩했습니다. 이제 클러스터 사용자는 자신의 배치에 PVC를 마운트하고 PV 오브젝트에서 읽거나 쓰기를 시작할 수 있습니다.

동적 프로비저닝을 사용하여 Stateful 세트를 작성할 때 PVC 작성

Stateful 세트를 작성할 때 PVC를 자동으로 작성하려면 이 선택사항을 사용하십시오.

시작하기 전에: 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.

1. 클러스터 내의 모든 기존 Stateful 세트가 완전히 배치되었는지 확인하십시오. 특정 Stateful 세트가 여전히 배치 중인 경우에는 Stateful 세트 작성을 시작할 수 없습니다. 예기치 않은 결과를 방지하려면 클러스터 내의 모든 Stateful 세트가 완전히 배치될 때까지 기다려야 합니다. 클러스터에 있는 기존 Stateful 세트를 나열하십시오.

   kubectl get statefulset --all-namespaces
   

   출력 예

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. 각 Stateful 세트의 Pods Status를 보고 해당 Stateful 세트의 배치가 완료되었는지 확인하십시오.

   kubectl describe statefulset <statefulset_name>
   

   출력 예

   Name:               nginx
   Namespace:          default
   CreationTimestamp:  Fri, 05 Oct 2022 13:22:41 -0400
   Selector:           app=nginx,billingType=hourly,region=us-south,zone=dal10
   Labels:             app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   Annotations:        kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
   Replicas:           3 desired | 3 total
   Pods Status:        0 Running / 3 Waiting / 0 Succeeded / 0 Failed
   Pod Template:
   Labels:  app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   

   CLI 출력의 Replicas 섹션이 Pods Status 섹션의 Running 팟(Pod) 수와 동일하면 Stateful 세트가 완전히 배치된 것입니다. Stateful 세트가 아직 완전히 배치되지 않은 경우에는 진행하기 전에 배치가 완료되기를 기다리십시오.

3. Stateful 세트에 대한 구성 파일과 이 Stateful 세트를 노출하는 데 사용하는 서비스를 작성하십시오.

   구역을 지정하는 상태 저장 세트 예. 다음 예는 NGINX를 3개의 복제본을 포함하는 Stateful 세트로 배치하는 방법을 보여줍니다. 각 복제본에 대해, ibmc-file-retain-bronze 스토리지 클래스의 스펙에 따라 20GB의 File Storage for Classic 디바이스가 프로비저닝됩니다. 모든 스토리지는 dal10 구역에서 프로비저닝됩니다. 다른 구역에서는 File Storage for Classic에 액세스할 수 없으므로 Stateful 세트의 모든 복제본 또한 dal10에 있는 작업자 노드에 배치됩니다.

   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
    name: nginx
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: Parallel
     selector:
       matchLabels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol
             mountPath: /usr/share/nginx/html
       volumeClaimTemplates:
       - metadata:
          name: myvol
         spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 20Gi
              iops: "300" #required only for performance storage
          storageClassName: ibmc-file-retain-bronze
   

   비선호도 규칙 및 지연된 File Storage for Classic 작성이 있는 상태 저장 세트 예. 다음 예는 NGINX를 3개의 복제본을 포함하는 Stateful 세트로 배치하는 방법을 보여줍니다. Stateful 세트는 File Storage for Classic가 작성된 지역 및 구역을 영역을 지정하지 않습니다. 대신, Stateful 세트는 반친화성 규칙을 사용하여 팟(Pod)이 작업자 노드와 구역에 걸쳐 분산되도록 합니다. 작업자 노드 반친화성은 app: nginx 레이블을 정의하여 구현됩니다. 이 레이블은 동일한 레이블의 팟(Pod)이 이 작업자 노드에서 이미 실행되는 경우 작업자 노드에서 팟(Pod)을 스케줄하지 않도록 Kubernetes에 지시합니다. topologykey: failure-domain.beta.kubernetes.io/zone 레이블은 이 반친화성 규칙을 더 제한하며 app: nginx 레이블의 팟(Pod)을 이미 실행 중인 작업자 노드와 동일한 구역에 있는 작업자 노드에서 스케줄되지 않도록 합니다. 각 Stateful 세트 팟(Pod)에 대해 두 개의 PVC가 volumeClaimTemplates 섹션에 정의된 대로 작성되지만 File Storage for Classic 인스턴스의 작성은 스토리지를 사용하는 Stateful 세트 팟(Pod)이 스케줄될 때까지 지연됩니다. 이러한 구성을 ‘토폴로지를 고려한 볼륨 스케줄링’이라고 합니다.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-file-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-file
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: web
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: "Parallel"
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 100
               podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: app
                     operator: In
                     values:
                     - nginx
                 topologyKey: failure-domain.beta.kubernetes.io/zone
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol1
             mountPath: /usr/share/nginx/html
           - name: myvol2
             mountPath: /tmp1
     volumeClaimTemplates:
     - metadata:
         name: myvol1
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
   

   name

   metadata에서, Stateful 세트의 이름을 입력하십시오. 입력하는 이름은 <volume_name>-<statefulset_name>-<replica_number> 형식으로 PVC의 이름을 작성하는 데 사용됩니다.

   serviceName

   spec 섹션에서, Stateful 세트를 노출하는 데 사용할 서비스의 이름을 입력하십시오.

   replicas

   Stateful 세트의 복제본 수를 입력하십시오.

   podManagementPolicy

   Stateful 세트에 대해 사용할 팟(Pod) 관리 정책을 입력하십시오. 다음 옵션 중에 선택하십시오.

   • OrderedReady: 이 선택사항을 사용하면 Stateful 세트 복제본이 순서대로 배치됩니다. 예를 들어 3개의 복제본을 지정한 경우, Kubernetes는 첫 번째 복제본의 PVC를 작성하고, 이 PVC가 바인드될 때까지 기다리고, Stateful 세트 복제본을 배치하고, PVC를 복제본에 마운트합니다. 이 배치가 완료되고 나면 두 번째 복제본이 배치됩니다. 이 옵션에 대한 자세한 내용은 OrderedReady 의 ‘Pod 관리’를 참조하십시오.
   • Parallel: 이 옵션을 사용하면 모든 상태 저장 세트 복제본의 배치가 동시에 시작됩니다. 앱에서 복제본의 병렬 배치를 지원하는 경우에는 PVC 및 Stateful 세트 복제본의 배치 시간을 절약하기 위해 이 선택사항을 사용하십시오.

   matchLabels

   spec selector 섹션에서, Stateful 세트 및 PVC에 포함시킬 모든 레이블을 입력하십시오. Stateful 세트의 volumeClaimTemplates에 포함하는 레이블은 Kubernetes가 인식하지 않습니다. 다음 샘플 레이블을 검토하십시오.

   • region 및 zone: 모든 Stateful 세트 복제본 및 PVC를 하나의 특정 구역에서 작성하려는 경우에는 두 레이블을 모두 추가하십시오. 사용하는 스토리지 클래스에 구역 및 지역을 지정할 수도 있습니다. 다중 구역 클러스터를 보유한 상태에서 구역 및 지역을 지정하지 않으면 모든 구역 간에 볼륨 요청의 균등한 밸런스를 유지하기 위해 스토리지가 프로비저닝되는 구역이 라운드 로빈 기반으로 선택됩니다.
   • billingType: PVC에 사용할 비용 청구 유형을 입력하십시오. hourly 또는 monthly 중에서 선택하십시오. 이 레이블을 지정하지 않으면 모든 PVC가 시간별 비용 청구 유형으로 작성됩니다.

   labels

   spec template metadata 섹션에서 spec.selector.matchLabels 섹션에 추가한 것과 동일한 레이블을 입력하십시오.

   affinity

   spec template spec affinity 섹션에서, Stateful 세트 팟(Pod)이 작업자 노드 및 구역 전체에 분산되도록 하기 위한 반친화성 규칙을 지정하십시오. 이 예는 Stateful 세트 팟(Pod)이 app: nginx 레이블이 있는 팟(Pod)이 실행되는 작업자 노드에서 스케줄되지 않는 것을 선호하는 반친화성 규칙을 보여줍니다. topologykey: failure-domain.beta.kubernetes.io/zone은 이 반친화성 규칙을 더 제한하며 작업자 노드가 app: nginx 레이블이 있는 팟(Pod)과 동일한 구역에 있는 경우 팟(Pod)이 작업자 노드에서 스케줄되지 않도록 합니다. 이 반친화성 규칙을 사용하면 작업자 노드 및 구역에 대해 반친화성을 구현할 수 있습니다.

   name

   spec volumeClaimTemplates metadata 섹션에서, 볼륨의 이름을 입력하십시오. spec.containers.volumeMount.name 섹션에 정의한 것과 동일한 이름을 사용하십시오. 여기에 입력하는 이름은 <volume_name>-<statefulset_name>-<replica_number> 형식으로 PVC의 이름을 작성하는 데 사용됩니다.

   storage

   spec volumeClaimTemplates spec resources requests 섹션에서, File Storage for Classic의 크기를 기가바이트(Gi) 단위로 입력하십시오.

   iops

   spec volumeClaimTemplates spec resources requests 섹션에서, Performance 스토리지를 프로비저닝하려는 경우에는 IOPS 수를 입력하십시오. Endurance 스토리지 클래스를 사용하면서 IOPS 수를 지정하면 IOPS 수가 무시됩니다. 대신 스토리지 클래스에 지정된 IOPS가 사용됩니다.

   storageClassName

   spec volumeClaimTemplates spec 섹션에서, 사용할 스토리지 클래스를 입력하십시오. 기존 스토리지 클래스를 나열하려면 kubectl get sc | grep file``을 실행하십시오. 스토리지 클래스를 지정하지 않으면 클러스터에 설정된 기본 스토리지 클래스를 사용하여 PVC가 작성됩니다. Stateful 세트가 File Storage for Classic를 사용하여 프로비저닝되도록 기본 스토리지 클래스가 ibm.io/ibmc-file 프로비저너를 사용하는지 확인하십시오.

4. Stateful 세트를 작성하십시오.

   kubectl apply -f statefulset.yaml
   

5. Stateful 세트가 배치될 때까지 기다리십시오.

   kubectl describe statefulset <statefulset_name>
   

PVC의 현재 상태를 보려면 kubectl get pvc를 실행하십시오. PVC의 이름은 <volume_name>-<statefulset_name>-<replica_number>로 형식화됩니다.

정적 프로비저닝: Stateful 세트와 함께 기존 PVC 사용

Stateful 세트를 작성하기 전에 PVC를 사전 프로비저닝하거나 기존 PVC를 Stateful 세트와 함께 사용할 수 있습니다.

Stateful 세트를 작성할 때 동적으로 PVC를 프로비저닝하는 경우, PVC의 이름은 Stateful 세트 YAML 파일에 사용한 값에 따라 지정됩니다. Stateful 세트가 기존 PVC를 사용하기 위해서는 PVC의 이름이 동적 프로비저닝을 사용할 때 자동으로 작성되는 이름과 일치해야 합니다.

시작하기 전에: 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.

1. Stateful 세트를 작성하기 전에 사전 프로비저닝하려는 경우, 앱에 File Storage for Classic 추가의 1 - 3단계에 따라 각 Stateful 세트 복제본에 대한 PVC를 작성하십시오. <volume_name>-<statefulset_name>-<replica_number> 형식을 따르는 이름을 사용하여 PVC를 작성해야 합니다.

<volume_name>

Stateful 세트의 spec.volumeClaimTemplates.metadata.name 섹션에 지정할 이름을 사용하십시오(예: nginxvol).

<statefulset_name>

Stateful 세트의 metadata.name 섹션에 지정할 이름을 사용하십시오(예: nginx_statefulset).

<replica_number>

0부터 시작하는 복제본의 번호를 입력하십시오.

예를 들어, 3개의 Stateful 세트 복제본을 작성해야 하는 경우에는 nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1 및 nginxvol-nginx_statefulset-2와 같은 이름을 가진 3개의 PVC를 작성하십시오.

기존 File Storage for Classic 인스턴스에 대한 PVC 및 PV를 작성하시겠습니까? 정적 프로비저닝을 사용하여 PVC 및 PV를 작성하십시오.

1. 동적 프로비저닝: Stateful 세트를 작성할 때 PVC 작성의 단계에 따라 Stateful 세트를 작성하십시오. PVC의 이름은 <volume_name>-<statefulset_name>-<replica_number> 형식을 따릅니다. 상태 저장 세트 스펙의 PVC 이름에서 다음 값을 사용해야 합니다.

spec.volumeClaimTemplates.metadata.name

PVC 이름의 <volume_name>을 입력하십시오.

metadata.name

PVC 이름의 <statefulset_name>을 입력하십시오.

spec.replicas

Stateful 세트에 대해 작성할 복제본의 수를 입력하십시오. 복제본의 수는 이전에 작성한 PVC의 수와 동일해야 합니다.

PVC가 다른 구역에 있는 경우, Stateful 세트에 지역 또는 구역 레이블을 포함하지 마십시오.

1. 클러스터에서 팟(pod)을 나열하고 상태 저장 세트에 속하는 팟(pod)을 식별하여 PVC가 상태 저장 세트 복제본 팟(pod)에서 사용되는지 확인하십시오.

   kubectl get pods
   

2. 기존 PVC가 Stateful 세트 복제본에 마운트되었는지 확인하십시오. CLI 출력의 ClaimName 섹션에 있는 **Volumes**을 검토하십시오.

   kubectl describe pod <pod_name>
   

   출력 예

   Name:           nginx-0
   Namespace:      default
   Node:           10.xxx.xx.xxx/10.xxx.xx.xxx
   Start Time:     Fri, 05 Oct 2022 13:24:59 -0400
   ...
   Volumes:
   myvol:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  myvol-nginx-0
   ...
   

특정 NFS 버전을 사용하는 사용자 정의 스토리지 클래스 생성

1. 프로비저닝하고자 하는 NFS 버전으로 사용자 정의된 스토리지 클래스를 작성하십시오.

2. 클러스터에 스토리지 클래스를 작성하십시오.

   kubectl apply -f nfsversion_storageclass.yaml
   

3. 사용자 정의된 스토리지 클래스가 작성되었는지 확인하십시오.

   kubectl get sc
   

4. 사용자 정의된 스토리지 클래스로 File Storage for Classic를 프로비저닝하십시오.

기존 PV를 다른 NFS 버전을 사용하도록 변경하기

1. NFS 버전을 변경할 File Storage for Classic의 PV를 가져오고 PV의 이름을 기록해 두십시오.

   kubectl get pv
   

2. PV에 어노테이션을 추가하십시오. <version_number>를 사용할 NFS 버전으로 대체하십시오. 예를 들어, NFS 버전 3.0으로 변경하려면 3을 입력하십시오.

   kubectl patch pv <pv_name> -p '{"metadata": {"annotations":{"volume.beta.kubernetes.io/mount-options":"vers=<version_number>"}}}'
   

3. File Storage for Classic를 사용하는 팟(Pod)을 삭제하고 팟(Pod)을 다시 작성하십시오.

   1. 팟(Pod) YAML을 로컬 머신에 저장하십시오.

       kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
       ```
   2. 팟(Pod)을 삭제하십시오.
   
   ```sh {: pre}
       kubectl deleted pod <pod_name>
       ```
   3. 팟(Pod)을 다시 작성하십시오.
   
   ```sh {: pre}
       kubectl apply -f pod.yaml
       ```
   

4. 팟(Pod)이 배치될 때까지 기다리십시오. 상태가 Running으로 변경되면 팟(Pod)이 완전히 배치된 것입니다.

   kubectl get pods
   

5. 팟(Pod)에 로그인하십시오.

   kubectl exec -it <pod_name> sh
   

6. File Storage for Classic가 이전에 지정한 NFS 버전으로 마운트되었는지 확인하십시오.

   mount | grep "nfs" | awk -F" |," '{ print $5, $8 }'
   

   출력 예

   nfs vers=3.0
   

정기적 스냅샷 설정

특정 시점에 인스턴스 상태를 캡처하는 읽기 전용 이미지인 File Storage for Classic에 대한 주기적 스냅샷을 설정할 수 있습니다. 스냅샷을 저장하려면 File Storage for Classic의 스냅샷 영역을 요청해야 합니다. 스냅샷은 동일한 구역 내의 기본 스토리지 인스턴스에 저장됩니다. 사용자가 실수로 볼륨에서 중요한 데이터를 제거한 경우 스냅샷에서 데이터를 복원할 수 있습니다.

볼륨의 스냅샷을 작성하려면 다음 단계를 완료하십시오.

1. 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.

2. ibmcloud sl CLI에 로그인하십시오.

   ibmcloud sl init
   

3. 클러스터에 있는 기존 PV를 나열하십시오.

   kubectl get pv
   

4. 스냅샷 영역을 작성할 PV에 대한 세부사항을 가져오고 볼륨 ID, 크기 및 IOPS를 기록해 두십시오. 볼륨 ID, 크기 및 IOPS는 CLI 출력의 Labels 섹션에서 찾을 수 있습니다.

   kubectl describe pv <pv_name>
   

5. 이전 단계에서 검색한 매개변수를 사용하여 기존 볼륨의 스냅샷 크기를 작성하십시오.

   ibmcloud sl file snapshot-order <volume_ID> --size <size> --tier <iops>
   

6. 스냅샷 크기가 작성될 때까지 기다리십시오. CLI 출력의 **Snapshot Size (GB)**가 0에서 주문한 크기로 변경된 경우 스냅샷 크기가 성공적으로 프로비저닝된 것입니다.

   ibmcloud sl file volume-detail <volume_ID>
   

7. 볼륨에 대한 스냅샷을 작성하고 작성된 스냅샷의 ID를 기록해 두십시오.

   ibmcloud sl file snapshot-create <volume_ID>
   

8. 스냅샷이 작성되었는지 확인하십시오.

   ibmcloud sl file snapshot-list <volume_ID>
   

9. 스냅샷 스케줄을 설정하십시오. 스냅샷 스케줄에 사용 가능한 옵션에 대한 자세한 정보는 CLI 문서 를 참조하십시오.

   ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
   

10. 스냅샷의 데이터를 기존 볼륨에 복원하려면 다음 명령을 실행하십시오.

    ibmcloud sl file snapshot-restore <volume_ID> <snapshot_ID>
    

다른 구역에 스냅샷 복제

구역 장애로부터 데이터를 보호하기 위해 다른 구역에서 설정된 File Storage for Classic 인스턴스로 스냅샷을 복제할 수 있습니다.

데이터는 기본 스토리지에서 백업 스토리지로만 복제할 수 있습니다. 복제된 File Storage for Classic 인스턴스를 클러스터에 마운트할 수는 없습니다. 기본 스토리지에서 장애가 발생하는 경우에는 복제된 백업 스토리지가 기본 스토리지가 되도록 수동으로 설정할 수 있습니다. 그런 다음 클러스터에 이를 추가할 수 있습니다. 기본 스토리지가 복원되고 나면 백업 스토리지로부터 데이터를 복원할 수 있습니다.

스토리지 복제

원본 스토리지 인스턴스와 동일한 구역에서 File Storage for Classic 인스턴스를 복제할 수 있습니다.

복제본(duplicate)에는 복제본(duplicate)을 작성한 시점의 원본 스토리지 인스턴스와 동일한 데이터가 저장되어 있습니다. 복제본(replica)과 다르게 복제본(duplicate)은 원본과 별개인 스토리지 인스턴스로 사용하십시오. 복제하려면 우선 볼륨에 대한 스냅샷을 설정하십시오.

IBM Cloud® Object Storage에 데이터 백업

ibm-backup-restore Helm 차트를 사용하여 클러스터에서 백업을 회전하고 팟(Pod)을 복원할 수 있습니다.

이 팟(Pod)에는 클러스터의 지속적 볼륨 클레임(PVC)에 대한 일회성 또는 주기적 백업을 실행하는 스크립트가 포함되어 있습니다. 데이터는 구역에 설정된 IBM Cloud® Object Storage 인스턴스에 저장됩니다.

데이터의 고가용성을 개선하고 구역 장애로부터 앱을 보호하려면 두 번째 IBM Cloud® Object Storage 인스턴스를 설정하고 구역 간에 데이터를 복제하십시오. IBM Cloud® Object Storage 인스턴스에서 데이터를 복원해야 하는 경우 Helm 차트와 함께 제공되는 복원 스크립트를 사용하십시오.

팟(pod) 및 컨테이너에 대해 데이터 복사

kubectl cp 명령어를 사용하면 클러스터 내의 파드나 특정 컨테이너로, 또는 그곳에서 파일과 디렉터리를 복사할 수 있습니다.

시작하기 전에: 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오. -c를 사용하여 컨테이너를 지정하지 않으면 명령이 팟(Pod)에서 사용 가능한 첫 번째 컨테이너를 사용합니다.

로컬 시스템의 데이터를 클러스터의 팟(pod)에 복사하십시오.

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>

클러스터의 팟(pod)에 있는 데이터를 로컬 시스템에 복사하십시오.

kubectl cp <namespace>/<pod>:<pod_filepath>/<filename></var> <local_filepath>/<filename>

로컬 시스템의 데이터를 클러스터의 팟(pod)에서 실행하는 특정 컨테이너에 복사하십시오.

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath> -c CONTAINER

토폴로지 인식 스토리지 작성

다중 구역 클러스터에서 File Storage for Classic를 사용하려면 볼륨을 읽고 쓸 수 있도록 File Storage for Classic 인스턴스와 동일한 구역에서 팟(Pod)이 스케줄되어야 합니다. Kubernetes가 토폴로지 인식 볼륨 스케줄링을 도입하기 전에 스토리지를 동적으로 프로비저닝하면 PVC가 작성될 때 File Storage for Classic 인스턴스가 자동으로 작성되었습니다. 그런 다음, 팟(Pod)을 작성할 때 Kubernetes 스케줄러는 File Storage for Classic 인스턴스와 동일한 데이터 센터의 작업자 노드에 팟(Pod)을 배치하려고 했습니다.

팟(Pod)의 제한조건을 모르고 File Storage for Classic 인스턴스를 작성하면 원하지 않는 결과가 발생할 수 있습니다. 예를 들어, 작업자 노드에 리소스가 충분하지 않거나 작업자 노드가 오염되어 팟(Pod)이 스케줄될 수 없어 팟(Pod)이 스토리지와 동일한 작업자 노드에 스케줄되지 않을 수도 있습니다. 토폴로지 인식 볼륨 스케줄링을 사용하면 스토리지를 사용하는 첫 번째 팟(Pod)이 작성될 때까지 File Storage for Classic 인스턴스가 지연됩니다.

다음 예제는 이 스토리지를 사용하는 첫 번째 팟(Pod)이 스케줄될 준비가 될 때까지 File Storage for Classic 인스턴스 작성을 지연시키는 스토리지 클래스를 작성하는 방법을 보여줍니다. 작성을 지연하려면 volumeBindingMode: WaitForFirstConsumer 옵션을 포함해야 합니다. 이 옵션을 포함하지 않으면 volumeBindingMode가 자동으로 Immediate로 자동 설정되며 PVC를 작성할 때 File Storage for Classic 인스턴스가 작성됩니다.

내구성 File Storage for Classic의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-bronze-delayed
parameters:
  billingType: hourly
  classVersion: "2"
  iopsPerGB: "2"
  sizeRange: '[20-12000]Gi'
  type: Endurance
  provisioner: ibm.io/ibmc-file
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer

성능 File Storage for Classic의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
 billingType: "hourly"
 classVersion: "2"
 sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
 type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

다중 구역 클러스터에 대한 구역 지정

특정 구역에 File Storage for Classic를 작성하려는 경우 사용자 정의 스토리지 클래스에 구역과 지역을 지정할 수 있습니다.

특정 구역에서 정적으로 File Storage for Classic를 프로비저닝하려는 경우에는 사용자 정의된 스토리지 클래스를 사용하십시오. 그 외의 모든 경우에는 PVC에 구역을 직접 지정하십시오.

사용자 정의된 스토리지 클래스를 작성하는 경우 클러스터 및 작업자 노드가 있는 동일한 지역 및 구역을 지정하십시오. 클러스터의 지역을 가져오려면 ibmcloud ks cluster get --cluster <cluster_name_or_ID>를 실행하여 마스터 URL에서 지역 접두부를 찾으십시오(예: https://c2.eu-de.containers.cloud.ibm.com:11111에서 eu-de). 작업자 노드의 구역을 가져오려면 ibmcloud ks worker ls --cluster <cluster_name_or_ID>를 실행하십시오.

내구성 File Storage for Classic의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-silver-mycustom-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
reclaimPolicy: Delete
volumeBindingMode: Immediate

성능 File Storage for Classic의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  billingType: "hourly"
  classVersion: "2"
  sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
  type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: Immediate

기본 NFS 버전 변경

다음 사용자 정의된 스토리지 클래스는 프로비저닝하려는 NFS 버전을 정의할 수 있도록 허용합니다. 예를 들어, NFS 버전 3.0을 프로비저닝하려면 <nfs_version>을 3.0으로 대체하십시오.

내구성 File Storage for Classic의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
  mountOptions: nfsvers=<nfs_version>

성능 File Storage for Classic의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Performance"
  classVersion: "2"
  sizeIOPSRange: |-
    "[20-39]Gi:[100-1000]"
    "[40-79]Gi:[100-2000]"
    "[80-99]Gi:[100-4000]"
    "[100-499]Gi:[100-6000]"
    "[500-999]Gi:[100-10000]"
    "[1000-1999]Gi:[100-20000]"
    "[2000-2999]Gi:[200-40000]"
    "[3000-3999]Gi:[200-48000]"
    "[4000-7999]Gi:[300-48000]"
    "[8000-9999]Gi:[500-48000]"
    "[10000-12000]Gi:[1000-48000]"
  mountOptions: nfsvers=<nfs_version>

스토리지 제거 옵션 이해

IBM Cloud 계정에서 지속적 스토리지를 제거하는 것은 스토리지를 프로비저닝한 방식과 이미 제거한 컴포넌트에 따라 다릅니다.

클러스터를 삭제하면 내 영구 저장소도 삭제되나요?

클러스터 삭제 중에 지속적 스토리지를 제거하는 옵션이 있습니다. 그러나 스토리지가 프로비저닝된 방식에 따라 스토리지 제거에는 모든 스토리지 컴포넌트가 포함되지 않을 수 있습니다. reclaimPolicy: Delete 가 설정된 스토리지 클래스를 사용하여 스토리지를 동적으로 프로비저닝한 경우, 클러스터를 삭제하면 PVC, PV 및 스토리지 인스턴스가 자동으로 삭제됩니다. 정적으로 프로비저닝된 스토리지나 reclaimPolicy: Retain``을 설정하는 스토리지 클래스를 사용하여 프로비저닝한 스토리지의 경우, 클러스터를 삭제하면 PVC와 PV는 제거되지만 스토리지 인스턴스와 데이터는 그대로 유지됩니다. 계속해서 스토리지 인스턴스에 대한 비용이 청구됩니다. 또한 비정상 상태에서 클러스터를 삭제한 경우, 제거를 선택했어도 스토리지가 아직 존재할 수 있습니다.

클러스터는 그대로 두고 스토리지만 삭제하려면 어떻게 해야 하나요?

reclaimPolicy: Delete를 설정하는 스토리지 클래스로 스토리지를 동적으로 프로비저닝한 경우 PVC를 제거하여 지속적 스토리지의 삭제 프로세스를 시작할 수 있습니다. 사용자 PVC, PV 및 스토리지 인스턴스가 자동으로 제거됩니다. 정적으로 프로비저닝된 스토리지 또는 reclaimPolicy: Retain``를 설정하는 스토리지 클래스를 사용하여 프로비저닝한 스토리지의 경우, 추가 요금이 부과되지 않도록 PVC, PV 및 스토리지 인스턴스를 수동으로 제거해야 합니다.

저장 공간을 삭제하면 요금이 어떻게 중단되나요?

삭제하는 스토리지 컴포넌트 항목과 시점에 따라 비용 청구 주기가 즉시 중지되지 않을 수 있습니다. PVC 및 PV를 삭제하지만 IBM Cloud 계정의 스토리지 인스턴스는 삭제하지 않은 경우, 해당 인스턴스는 계속 존재하게 되며 이에 대한 비용을 지불하게 됩니다.

PVC, PV 및 스토리지 인스턴스를 삭제하는 경우 비용 청구 주기는 스토리지를 프로비저닝할 때 선택한 billingType과 스토리지를 삭제하도록 선택한 방식에 따라 달라집니다.

• IBM Cloud 콘솔이나 CLI에서 영구 스토리지 인스턴스를 수동으로 취소하면 다음과 같이 과금이 중단됩니다

  • 시간별 스토리지: 비용 청구가 즉시 중지됩니다. 스토리지가 취소된 후 최대 72시간 동안 스토리지 인스턴스가 콘솔에 표시될 수 있습니다.
  • 월별 스토리지: 즉시 취소 또는 기념일에 취소 중에서 선택할 수 있습니다. 두 경우 모두 현재 비용 청구 주기가 끝날 때까지 계속해서 비용이 청구되며 다음 비용 청구 주기에 대한 비용 청구가 중지됩니다. 스토리지가 취소된 후 최대 72시간 동안 스토리지 인스턴스가 콘솔 또는 CLI에 표시될 수 있습니다.
  • 즉시 취소: 스토리지를 즉시 제거할 경우 이 옵션을 선택합니다. 사용자가 스토리지를 더 이상 사용하지 않거나 데이터를 복구하지 않는 경우가 해당됩니다.
  • 기념일: 다음 기념일에 스토리지를 취소할 경우 이 옵션을 선택합니다. 예를 들어, 데이터를 백업할 시간을 팀에 알려주기 위해 스토리지 인스턴스는 다음 기념일까지 활성 상태로 유지되며 이 날짜까지 계속해서 사용할 수 있습니다.

• reclaimPolicy: Delete를 설정하는 스토리지 클래스로 스토리지를 동적으로 프로비저닝하고 PVC를 제거하도록 선택하는 경우 PV 및 스토리지 인스턴스가 즉시 제거됩니다. 매시간 비용 청구된 스토리지의 경우, 비용 청구가 즉시 중지됩니다. 매월 청구되는 스토리지의 경우 해당 월의 나머지에 대해 비용이 청구됩니다. 스토리지가 제거되고 비용 청구가 중지된 후 최대 72시간 동안 스토리지 인스턴스가 콘솔 또는 CLI에 표시될 수 있습니다.

영구 저장소를 삭제하기 전에 무엇을 주의해야 하나요?

지속적 스토리지를 정리하면 그 안에 저장된 모든 데이터가 삭제됩니다. 데이터 사본이 필요한 경우 백업을 만드세요.

저장소 인스턴스를 삭제했습니다. 왜 내 인스턴스가 여전히 표시되나요?

지속적 스토리지를 제거한 후 제거가 완전히 처리되고 IBM Cloud 콘솔 또는 CLI에서 스토리지가 표시되지 않으려면 최대 72 시간이 걸릴 수 있습니다.

지속적 스토리지 정리

지속적 스토리지에 대한 추가 비용이 부과되지 않도록 IBM Cloud 계정에서 PVC, PV 및 스토리지 인스턴스를 제거합니다.

시작하기 전에:

• 보존할 데이터를 백업했는지 확인하십시오.
• 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.

지속적 데이터를 정리하려면 다음을 수행하십시오.

1. 클러스터의 PVC를 나열하고 PVC의 NAME, STORAGECLASS, 그리고 PVC에 바인드되고 **VOLUME**으로 표시되는 PV의 이름을 기록해 두십시오.

   kubectl get pvc
   

   출력 예

   NAME                  STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS            AGE
   claim1   Bound     pvc-06886b77-102b-11e8-968a-f6612bb731fb   20Gi       RWO           class       78d
   claim2     Bound     pvc-457a2b96-fafc-11e7-8ff9-b6c8f770356c   4Gi        RWX           class 105d
   claim3      Bound     pvc-1efef0ba-0c48-11e8-968a-f6612bb731fb   24Gi       RWX           class        83d
   

2. 스토리지 클래스에 대한 ReclaimPolicy 및 **billingType**을 검토하십시오.

   kubectl describe storageclass <storageclass_name>
   

   재확보 정책에서 Delete를 표시하는 경우에는 PVC를 제거할 때 PV 및 실제 스토리지가 제거됩니다. 재확보 정책에서 Retain을 표시하거나 사용자가 스토리지 클래스 없이 스토리지를 프로비저닝한 경우에는 PVC를 제거할 때 PV 및 실제 스토리지가 제거되지 않습니다. 사용자가 PVC, PV 및 실제 스토리지를 개별적으로 제거해야 합니다.

   스토리지가 매월 비용 청구되는 경우에는 비용 청구 주기가 종료되기 전에 스토리지를 제거해도 여전히 해당 월 전체에 대해 비용이 청구됩니다.

3. PVC를 마운트하는 팟(Pod)을 제거하십시오. PVC를 마운트하는 팟(Pod)을 나열하십시오. 팟(Pod)이 CLI 출력에서 리턴되지 않으면 PVC를 사용하는 팟(Pod)이 없는 것입니다.

   kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
   

   출력 예

   depl-12345-prz7b:    claim1
   

4. PVC를 사용하는 팟(Pod)을 제거하십시오. 팟(Pod)이 배치의 일부인 경우에는 배치를 제거하십시오.

   kubectl delete pod <pod_name>
   

5. 팟(Pod)이 제거되었는지 확인하십시오.

   kubectl get pods
   

6. PVC를 제거하십시오.

   kubectl delete pvc <pvc_name>
   

7. PV의 상태를 검토하십시오. 이전에 검색한 PV의 이름을 **VOLUME**으로 사용하십시오. PVC를 제거하면 PVC에 바인드된 PV가 릴리스됩니다. 스토리지를 프로비저닝하는 방법에 따라, PV는 Deleting 상태(PV가 자동 삭제되는 경우) 또는 Released 상태(PV를 수동 삭제해야 하는 경우)가 됩니다. 참고: 자동 삭제되는 PV의 경우에는 삭제되기 전에 상태가 잠시 Released로 표시될 수 있습니다. 잠시 후에 명령을 다시 실행하면 PV가 제거되었는지 여부를 볼 수 있습니다.

   kubectl get pv <pv_name>
   

8. PV가 삭제되지 않은 경우에는 PV를 수동으로 제거하십시오.

   kubectl delete pv <pv_name>
   

9. PV가 제거되었는지 확인하십시오.

   kubectl get pv
   

10. PV가 가리키는 실제 스토리지 인스턴스를 나열하고 실제 스토리지 인스턴스의 **id**를 기록해 두십시오.

    ibmcloud sl file volume-list --columns id  --columns notes | grep <pv_name>
    

    File Storage for Classic에 대한 출력 예.

    id         notes   
    12345678   {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}
    

    "plugin":"ibm-file-plugin-5b55b7b77b-55bb7"

    클러스터가 사용하는 스토리지 플러그인입니다.

    "region":"us-south"

    클러스터가 있는 지역입니다.

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    스토리지 인스턴스와 연관된 클러스터 ID입니다.

    "type":"Endurance"

    파일 또는 블록 스토리지의 유형(Endurance 또는 Performance)입니다.

    "ns":"default"

    스토리지 인스턴스가 배치되는 네임스페이스입니다.

    "pvc":"mypvc"

    스토리지 인스턴스와 연관된 PVC의 이름입니다.

    "pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"

    스토리지 인스턴스와 연관된 PV입니다.

    "storageclass":"ibmc-file-gold"

    스토리지 클래스의 유형(브론즈, 실버, 골드 또는 사용자 정의)입니다.

11. 실제 스토리지 인스턴스를 제거하십시오.

    ibmcloud sl file volume-cancel <classic_file_id>
    

12. 실제 스토리지 인스턴스가 제거되었는지 확인하십시오.

    ibmcloud sl file volume-list
    

삭제 프로세스는 완료되는 데 최대 72시간이 걸릴 수 있습니다.