IBM Cloud Block Storage 플러그인 업데이트

기존 IBM Cloud Block Storage 플러그인을 최신 버전으로 업그레이드할 수 있습니다.

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

1. Helm 저장소를 업데이트하여 이 저장소에 있는 모든 Helm 차트의 최신 버전을 검색하십시오.

   helm repo update
   

2. 선택사항: 최신 Helm 차트를 로컬 머신에 다운로드하십시오. 그런 다음, 패키지의 압축을 풀고 release.md 파일을 검토하여 최신 릴리스 정보를 찾으십시오.

   helm pull iks-charts/ibmcloud-block-storage-plugin --untar
   

3. 클러스터에 설치한 블록 스토리지 Helm 차트의 릴리스 이름 네임스페이스를 찾으십시오.

   helm ls -A
   

   출력 예

   NAME            NAMESPACE   REVISION    UPDATED                             STATUS      CHART                                   APP VERSION
   block-plugin    default     1           2022-01-21 09:02:46.11622 -0500 EST deployed        bmcloud-block-storage-plugin-v2.1.5
   

4. IBM Cloud Block Storage 플러그인을 최신 버전으로 업그레이드하십시오. 이전에 검색한 릴리스 이름 및 네임스페이스를 포함하십시오.

   helm upgrade RELEASE-NAME iks-charts/ibmcloud-block-storage-plugin -n NAMESPACE
   

5. 선택사항: 플러그인을 업데이트하면 default 스토리지 클래스가 설정 해제됩니다. 기본 스토리지 클래스를 자체 선정한 스토리지 클래스로 설정하려면 다음 명령을 실행하십시오.

   kubectl patch storageclass STORAGECLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

IBM Cloud Block Storage 플러그인 제거

클러스터에서 IBM Cloud Block Storage를 프로비저닝하고 사용하지 않으려면 Helm 차트를 설치 제거할 수 있습니다.

이 플러그인을 제거해도 기존 PVC, PV 또는 데이터는 제거되지 않습니다. 플러그인을 제거할 때는 모든 관련 팟(Pod) 및 디먼 세트만 클러스터에서 제거됩니다. 플러그인을 제거한 후에는 클러스터의 새 블록 스토리지를 프로비저닝하거나 기존 블록 스토리지 PVC 및 PV를 사용할 수 없습니다.

시작하기 전에:

• 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
• 블록 스토리지를 사용하는 클러스터에 PVC 또는 PV가 없는지 확인하십시오.

플러그인을 제거하려면 다음을 수행하십시오.

1. 클러스터에 설치한 블록 스토리지 Helm 차트의 릴리스 이름 및 네임스페이스를 찾으십시오.

   helm ls -A
   

   출력 예

   NAME            NAMESPACE   REVISION    UPDATED                             STATUS   CHART                                  APP VERSION
   block-plugin    default     1           2022-01-21 09:02:46.11622 -0500 EST deployed    ibmcloud-block-storage-plugin-v2.1.5
   

2. IBM Cloud Block Storage 플러그인을 삭제하십시오.

   helm uninstall NAME -n kube-system
   

3. 블록 스토리지 팟(Pod)이 제거되었는지 확인하십시오.

   kubectl get pods -n kube-system | grep block
   

   CLI 출력에 팟(Pod)이 표시되지 않으면 팟(Pod) 제거가 성공한 것입니다.

4. 블록 스토리지 클래스가 제거되었는지 확인하십시오. CLI 출력에 스토리지 클래스가 표시되지 않으면 스토리지 클래스 제거가 성공한 것입니다.

   kubectl get sc | grep block
   

사용자 정의 스토리지 클래스를 사용하여 볼륨 데이터 암호화하기

먼저 자체 스토리지 클래스를 생성한 다음, 암호화된 볼륨을 사용하는 앱을 배포할 수 있습니다.

다음 단계에서는 구성이 동일한 여러 개의 암호화된 블록 스토리지 인스턴스를 작성하기 위해 사용할 수 있는 암호화된 사용자 정의 스토리지 클래스를 작성하는 방법에 대해 설명합니다. IBM 제공 스토리지 클래스 중 하나를 사용하여 암호화된 PVC를 작성하려면 PVC에서 직접 Key Protect 인증 정보를 참조하여 이를 수행할 수 있습니다.

1. 스토리지 구성을 결정하십시오.

2. IBM 에서 제공하는 스토리지 클래스 중 하나를 기반으로, 암호화된 블록 스토리지 인스턴스를 프로비저닝하는 자체 스토리지 클래스를 생성하십시오. kubectl get sc <storageclass_name> -o yaml을 실행하여 스토리지 클래스의 세부사항을 검색할 수 있습니다. 다음 예는 ibmc-block-retain-bronze 스토리지 클래스를 기반으로 합니다.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <name> # Enter the name of the storage class. Example: my_custom_storageclass
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
     encrypted: "true" # Enter "true" to enable encryption.
     encryptionKeySecret: <secret_name> # # #nter the name of the secret that you created earlier.Example: my_secret
     encryptionKeyNamespace: <namespace> # # #nter the namespace where you created your secret. Example: default
   provisioner: ibm.io/ibmc-block
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   

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

   kubectl apply -f storageclass.yaml
   

4. 자체 스토리지 클래스를 사용하여 PVC를 생성함으로써 앱에 ‘ Block Storage for Classic ’를 추가하세요.

5. Block Storage for Classic 볼륨의 암호화를 확인하십시오.

Block Storage for Classic 시크릿을 참조하는 PVC 작성

Block Storage for Classic 인증 정보를 보유한 Kubernetes 시크릿을 지정하는 PVC를 작성하여 암호화된 Key Protect를 프로비저닝할 수 있습니다.

다음 단계에서는 암호화된 Key Protect 인스턴스를 작성하기 위해 PVC에서 Block Storage for Classic 인증 정보를 참조할 수 있는 방법을 보여줍니다. 각 PVC에서 Key Protect 인증 정보를 지정하지 않고 여러 개의 암호화된 볼륨을 작성하기 위해 암호화된 사용자 정의 스토리지 클래스를 작성할 수 있습니다.

1. 제공된Block Storage for Classic 스토리지 클래스를 검토하여 앱 요구사항을 가장 잘 충족하는 스토리지 클래스를 판별하십시오. 제공된 스토리지 클래스가 앱 요구사항을 충족시키지 못하는 경우에는 고유한 사용자 정의된 스토리지 클래스를 작성할 수 있습니다.

2. Key Protect 서비스 인증 정보를 저장한 Kubernetes 시크릿을 참조하는 PVC 구성 파일을 pvc.yaml이라는 이름으로 작성하십시오. 이 시크릿을 작성하려면 Block Storage for Classic의 암호화 설정을 참조하십시오.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: <pvc_name> # Enter a name for your PVC.
     annotations:
     volume.beta.kubernetes.io/storage-class: "<storage_class>" # Enter a storage class. To see a list of storageclasses run `kubectl get storageclasses`.
     labels:
       encrypted: "true"
       encryptionKeyNamespace: <namespace> # Enter the namespace where your secret was created.
       encryptionKeySecret: <secret_name> # Enter the name of the secret you created.
   spec:
     accessModes:
       - ReadWriteOnce
       resources:
       requests:
           storage: 20Gi
   

3. 클러스터에 PVC를 작성하십시오.

   kubectl apply -f pvc.yaml
   

4. PVC의 상태를 확인하십시오.

   kubectl get pvc
   

5. PVC가 바인드할 때까지 기다린 후 PVC를 사용하는 배치를 작성하십시오.

6. Block Storage for Classic 볼륨의 암호화를 확인하십시오.

Block Storage for Classic 볼륨의 암호화 확인

볼륨 마운트 경로를 확인하여 볼륨의 암호화를 확인할 수 있습니다.

1. 앱 팟(Pod)에 로그인하십시오. <pod_name>을 암호화된 Block Storage for Classic 볼륨을 마운트하는 팟(Pod)의 이름으로 대체하십시오.

   kubectl exec <pod_name> -it bash
   

2. 팟(Pod)의 파일 시스템을 나열하십시오.

   df -h
   

3. 암호화된 Block Storage for Classic 볼륨에 대한 파일 시스템 경로를 검토하십시오.

   • 암호화된 볼륨의 경로 구조는 /dev/mapper/<pvc-ID_encrypted>입니다. 이 예에서 암호화된 볼륨은 팟(Pod)의 /test 파일 경로에 마운트됩니다.

       Filesystem                                            Size  Used Avail Use% Mounted on
       overlay                                                98G  8.2G   85G   9% /
       tmpfs                                                  64M     0   64M   0% /dev
       tmpfs                                                 2.0G     0  2.0G   0% /sys/fs/cgroup
       /dev/mapper/pvc-a011a111-1111-1111-111a-aaa1a1111a11_encrypted   20G   45M   20G   1% /test
       ```
   * 암호화되지 않은 볼륨의 경로 구조는 `dev/mapper/<random_string>`입니다.
   
   ```sh {: screen}
       Filesystem                                     Size  Used Avail Use% Mounted on
       overlay                                         98G   16G   78G  17% /
       tmpfs                                           64M     0   64M   0% /dev
       tmpfs                                          7.9G     0  7.9G   0% /sys/fs/cgroup
       /dev/mapper/3600a09803830476e733f4e477370716e   24G   45M   24G   1% /test
       ```
   

Kubernetes 시크릿을 삭제하더라도 볼륨 데이터에 대한 액세스 권한은 취소되지 않습니다. 팟(Pod) 전용 배치를 작성한 경우 팟(Pod)을 삭제해야 합니다. 배치를 작성한 경우 배치를 삭제해야 합니다.

기존 블록 스토리지의 정보 검색

1. IBM Cloud 인프라 계정의 API 키를 검색하거나 생성하십시오.

   1. IBM Cloud 인프라 포털 에 로그인하십시오.
   2. 계정을 선택한 후 사용자, 사용자 목록을 선택하십시오.
   3. 자신의 사용자 ID를 찾으십시오.
   4. API 키 열에서 생성을 클릭하여 API 키를 생성하거나 보기를 클릭하여 기존 API 키를 보십시오.

2. IBM Cloud 인프라 계정의 API 사용자 이름을 검색하십시오.

   1. 사용자 목록 메뉴에서 자신의 사용자 ID를 선택하십시오.
   2. API 액세스 정보 섹션에서 API 사용자 이름을 찾으십시오.

3. IBM Cloud 인프라 CLI 플러그인에 로그인하십시오.

   ibmcloud sl init
   

4. IBM Cloud 인프라 계정의 사용자 이름 및 API 키를 사용하여 인증하도록 선택하십시오.

5. 이전 단계에서 검색한 사용자 이름 및 API 키를 입력하십시오.

6. 사용 가능한 블록 스토리지 디바이스를 나열하십시오.

   ibmcloud sl block volume-list
   

   출력 예

   id          username              datacenter   storage_type                capacity_gb   bytes_used   lunId   
   11111111    IBM01AAA1111111-1     wdc07        endurance_block_storage     45            -            2      
   

7. 볼륨 세부사항을 검색하십시오. <volume_ID>를 6단계에서 검색한 블록 스토리지 볼륨의 ID로 대체하십시오.

   ibmcloud sl block volume-detail <volume_ID>
   

   출력 예

   ID                         11111111
   User name                  IBM01AAA1111111-1   
   Type                       endurance_block_storage   
   Capacity (GB)              45   
   LUN Id                     2   
   IOPs                       100   
   Datacenter                 wdc07   
   Target IP                  10.XXX.XX.XXX  
   # of Active Transactions   0   
   Replicant Count            0
   

8. 클러스터에 마운트할 블록 스토리지 디바이스의 ID, Capacity, LUN Id, Datacenter 및 Target IP를 기록해 두십시오. 참고: 클러스터에 기존 스토리지를 마운트하려면 스토리지와 동일한 구역에 작업자 노드가 있어야 합니다. 작업자 노드의 구역을 확인하려면 ibmcloud ks worker ls --cluster <cluster_name_or_ID>를 실행하십시오.

지속적 볼륨(PV) 및 일치하는 지속적 볼륨 청구(PVC) 작성

1. 선택사항: retain 스토리지 클래스로 프로비저닝한 스토리지가 있으면 PVC를 제거할 때 PV 및 실제 스토리지 디바이스가 제거되지 않습니다. 클러스터의 스토리지를 재사용하려면 우선 PV를 제거해야 합니다. 기존 PV를 나열하고 지속적 스토리지에 속하는 PV를 찾으십시오. PV는 released 상태입니다.

   kubectl get pv
   

2. PV를 제거하십시오.

   kubectl delete pv <pv_name>
   

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

   kubectl get pv
   

4. PV에 대한 구성 파일을 작성하십시오. 이전에 검색한 매개변수를 포함하십시오.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: "block-storage-pv" # Enter a name for your PV. For example, my-static-pv.
     labels:
        failure-domain.beta.kubernetes.io/region: "<region>" # Example us-east.
        failure-domain.beta.kubernetes.io/zone: "<zone>" # Example: wdc04. See /docs/containers?topic=containers-regions-and-zones#zones-sz
   spec:
     capacity:
       storage: "<storage>"
     accessModes:
       - ReadWriteOnce
     flexVolume:
       driver: "ibm/ibmc-block"
       fsType: "<fs_type>" # Enter ext or xfs
       options:
         "Lun": "<Lun_ID>"
         "TargetPortal": "<TargetPortal>"
         "VolumeID": "<VolumeID>"
         "volumeName": "block-storage-pv" # Enter the same value as your PV name from metadata.name
   

   name

   PV에 이름을 지정하십시오. 예를 들어, block-storage-pv입니다. 또한 spec.FlexVolume.options에 이 값을 volumeName으로 입력해야 합니다.

   labels

   이전에 검색한 지역 및 구역을 입력하십시오. 클러스터에서 스토리지를 마운트하려면 지속적 스토리지와 동일한 지역 및 구역에 작업자 노드가 최소한 하나 이상 있어야 합니다. 볼륨 세부사항을 검색하려면 ibmcloud sl block volume-list를 실행하여 볼륨 ID를 가져온 후 ibmcloud sl block volume-detail <volume_ID>를 실행하여 볼륨의 세부사항을 가져오십시오.

   region

   블록 스토리지가 있는 지역을 입력하십시오. 클러스터와 블록 스토리지는 동일한 지역에 있어야 합니다. 클러스터 위치를 찾으려면 ibmcloud ks cluster ls를 실행하십시오. 사용 가능한 지역 및 구역에 대한 자세한 정보는 지역 및 구역을 참조하십시오. 예: us-east.

   zone

   스토리지 볼륨이 있는 구역을 입력하십시오. 볼륨 세부사항을 검색하려면 ibmcloud sl block volume-list를 실행하여 볼륨 ID를 가져온 후 ibmcloud sl block volume-detail <volume_ID>를 실행하여 볼륨의 세부사항을 가져오십시오. 블록 스토리지를 클러스터에 연결하려면 연결하려는 볼륨과 동일한 구역에서 사용 가능한 작업자 노드가 있어야 합니다. 작업자 노드의 구역을 찾으려면 ibmcloud ks worker ls -c <cluster>를 실행하십시오. 예: wdc04.

   storage

   클러스터에 연결 기존 블록 스토리지 볼륨의 스토리지 크기를 입력하십시오. 이 스토리지 크기는 기가바이트 단위로 기록해야 합니다(예: 20Gi(20GB) 또는 1000Gi(1TB)). 볼륨 세부사항을 검색하려면 ibmcloud sl block volume-list를 실행하여 볼륨 ID를 가져온 후 ibmcloud sl block volume-detail <volume_ID>를 실행하여 볼륨의 세부사항을 가져오십시오.

   fsType

   기존 블록 스토리지에 대해 구성된 파일 시스템 유형을 입력하십시오. ext4 또는 xfs 중에서 선택하십시오. 이 옵션을 지정하지 않으면 기본적으로 PV가 ext4로 설정됩니다. 잘못된 fsType이 정의된 경우 PV 작성에 성공하지만 PV를 팟(Pod)에 마운트하는 데 실패합니다. 볼륨 세부사항을 검색하려면 ibmcloud sl block volume-list를 실행하여 볼륨 ID를 가져온 후 ibmcloud sl block volume-detail <volume_ID>를 실행하여 볼륨의 세부사항을 가져오십시오.

   Lun

   블록 스토리지 볼륨의 LUN ID를 입력하십시오. 볼륨 세부사항을 검색하려면 ibmcloud sl block volume-list를 실행하여 볼륨 ID를 가져온 후 ibmcloud sl block volume-detail <volume_ID>를 실행하여 볼륨의 세부사항을 가져오십시오.

   TargetPortal

   블록 스토리지의 IP 주소를 입력하십시오. TargetPortal 매개변수를 검색하려면 ibmcloud sl block volume-list를 실행하여 볼륨 ID를 가져온 후 ibmcloud sl block volume-detail <volume_ID>를 실행하고 출력에서 Target IP를 기록하십시오.

   VolumeId

   블록 스토리지의 ID를 입력하십시오. 볼륨 세부사항을 검색하려면 ibmcloud sl block volume-list를 실행하십시오.

   volumeName

   PV 이름과 동일한 값을 입력하십시오. 예를 들어, block-storage-pv입니다.

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

   kubectl apply -f pv.yaml
   

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

   kubectl get pv
   

7. 다른 구성 파일을 작성하여 PVC를 작성하십시오. PVC가 이전에 작성한 PV와 일치하려면 storage 및 accessMode에 대해 동일한 값을 선택해야 합니다. storage-class 필드는 빈 문자열이어야 합니다. 이러한 필드 중에 PV와 일치하지 않는 것이 있는 경우에는 대신 새 PV가 자동으로 작성됩니다.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: block-storage-pvc
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: "20Gi"
     storageClassName: ""
   

8. PVC를 작성하십시오.

   kubectl apply -f static-pvc.yaml
   

9. PVC가 작성되어 이전에 작성한 PV에 바인딩되었는지 확인하십시오. 이 프로세스에는 몇 분 정도 소요될 수 있습니다.

   kubectl describe pvc static-pvc
   

   출력 예

   Name:          static-pvc
   Namespace:     default
   StorageClass:  
   Status:        Bound
   

10. 선택사항 다음 예제 팟(Pod) 구성 파일을 pod.yaml 파일로 저장하십시오.

    apiVersion: v1
    kind: Pod
    metadata:
      name: block-storage
      labels:
        app: block-storage
    spec:
      containers:
        - name: block-storage
          image: nginx
          command: ["/bin/sh"]
          args: ["-c", "while true; do date \"+%Y-%m-%d %H:%M:%S\"; sleep 3600; done"]
          workingDir: /home
          imagePullPolicy: Always
          ports:
            - containerPort: 80
          volumeMounts:
            - name: block-storage-pv
              mountPath: /home
      volumes:
        - name: block-storage-pv
          persistentVolumeClaim:
            claimName: block-storage-pvc
    

11. 클러스터에서 팟(Pod)을 작성하십시오.

    kubectl create -f pod.yaml
    

12. 팟(Pod)이 Running 상태가 된 후 로그를 가져오십시오.

    kubectl logs
    

    출력 예

    2022-01-21 16:11:00
    

PV를 작성하여 PVC에 바인딩했습니다. 그런 다음 블록 스토리지를 사용하는 앱을 배치했습니다. 이제 클러스터 사용자가 해당 배치에 PVC를 마운트하고 지속적 볼륨에서 읽기 및 쓰기를 시작할 수 있습니다.

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

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

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

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

1. 클러스터에 있는 기존 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를 세 개의 복제본을 포함하는 Stateful 세트로 배치하는 방법을 보여줍니다. 각 복제본에 대해, ibmc-block-retain-bronze 스토리지 클래스에 정의된 스펙에 따라 20기가바이트의 블록 스토리지 디바이스가 프로비저닝됩니다. 모든 스토리지는 dal10 구역에서 프로비저닝됩니다. 다른 구역에서는 블록 스토리지에 액세스할 수 없으므로 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" # Enter the region where your cluster is located.
       zone: "dal10"
   template:
     metadata:
     labels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     spec:
     containers:
     - name: nginx
       image: nginx
       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-block-retain-bronze
   

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

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-block-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-block
   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:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
   

   name

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

   serviceName

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

   replicas

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

   podManagementPolicy

   Stateful 세트에 대해 사용할 팟(Pod) 관리 정책을 입력하십시오.

   • OrderedReady: 이 선택사항을 사용하면 Stateful 세트 복제본이 순서대로 배치됩니다. 예를 들어, 세 개의 복제본을 지정한 경우, 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 섹션에서, 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 섹션에서, 블록 스토리지의 크기를 기가바이트(Gi) 단위로 입력하십시오.

   iops

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

   storageClassName

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

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>로 형식화됩니다.

스테이트풀 세트와 기존 PVC를 활용한 정적 프로비저닝

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

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

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

1. Stateful 세트를 작성하기 전에 PVC를 사전 프로비저닝하려는 경우, 앱에 블록 스토리지 추가의 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부터 시작하는 복제본의 수를 입력하십시오.

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

기존 스토리지 디바이스에 대한 PVC 및 PV를 작성하시겠습니까? 정적 프로비저닝을 사용하여 PVC 및 PV를 작성하십시오.

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

metadata.name

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

spec.replicas

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

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

1. 클러스터의 팟 (Pod) 을 나열하여 Stateful 세트 복제본 팟 (Pod) 에서 PVC가 사용되는지 확인하십시오. 자신의 Stateful 세트에 속한 팟(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
   ...
   

정기적 스냅샷 설정

특정 시점에 인스턴스 상태를 캡처하는 읽기 전용 이미지인 블록 스토리지에 대한 주기적 스냅샷을 설정할 수 있습니다.

스냅샷을 저장하려면 블록 스토리지의 스냅샷 영역을 요청해야 합니다. 스냅샷은 동일한 구역 내의 기본 스토리지 인스턴스에 저장됩니다. 사용자가 실수로 볼륨에서 중요한 데이터를 제거한 경우 스냅샷에서 데이터를 복원할 수 있습니다. \n \n **볼륨에 대한 스냅샷을 작성하려면 다음 단계를 완료하십시오.

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

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

   ibmcloud sl init
   

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

   kubectl get pv
   

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

   kubectl describe pv <pv_name>
   

5. 볼륨 ID을 찾으려면 CLI 출력의 ibm.io/network-storage-id 어노테이션을 검토하십시오.

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

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

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

   ibmcloud sl block volume-detail <volume_ID>
   

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

   ibmcloud sl block snapshot-create <volume_ID>
   

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

   ibmcloud sl block snapshot-list <volume_ID>
   

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

    ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
    

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

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

다른 구역에 스냅샷 복제

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

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

스토리지 복제

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

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

IBM Cloud® Object Storage에 데이터 백업

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

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

블록 스토리지는 RWO 액세스 모드로 마운트됩니다. This access allows only one pod to be mounted to the block storage at a time. 데이터를 백업하려면 스토리지에서 앱 팟(Pod)을 마운트 해제하고 이를 백업 팟(Pod)에 마운트한 후에 데이터를 백업하고 스토리지를 앱 팟(Pod)에 다시 마운트해야 합니다.

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

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

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

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

kubectl cp 명령을 실행할 때 -c를 사용하여 컨테이너를 지정하지 않으면 이 명령은 팟(Pod)에서 사용 가능한 첫 번째 컨테이너를 사용합니다.

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

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

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

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

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

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

브론즈

이름

ibmc-block-bronze

ibmc-block-retain-bronze

유형

Endurance 스토리지

파일 시스템

ext4

GB당 IOPS

2

크기 범위(GB)

20 - 12000Gi

하드 디스크

SSD

재확보 정책

ibmc-block-bronze: 삭제

ibmc-block-retain-bronze: 유지

실버

이름

ibmc-block-silver

ibmc-block-retain-silver

유형

Endurance 스토리지

파일 시스템

ext4

GB당 IOPS

4

크기 범위(GB)

20 - 12000Gi

하드 디스크

SSD

재확보 정책

ibmc-block-silver: 삭제

ibmc-block-retain-silver: 유지

골드

이름

ibmc-block-gold

ibmc-block-retain-gold

유형

Endurance 스토리지

파일 시스템

ext4

GB당 IOPS

10

크기 범위(GB)

20 - 4000Gi

하드 디스크

SSD

재확보 정책

ibmc-block-gold: 삭제

ibmc-block-retain-gold: 유지

사용자 정의

이름

ibmc-block-custom

ibmc-block-retain-custom

유형

성능 파일 시스템

ext4

IOPS 및 크기

크기 범위(기가바이트) / IOPS 범위(100의 배수)

• 20-39Gi / 100-1000 IOPS
• 40-79Gi / 100-2000 IOPS
• 80-99Gi / 100-4000 IOPS
• 100-499Gi / 100-6000 IOPS
• 500-999Gi / 100-10000 IOPS
• 1000-1999Gi / 100-20000 IOPS
• 2000-2999Gi / 200-40000 IOPS
• 3000-3999Gi / 200-48000 IOPS
• 4000-7999Gi / 300-48000 IOPS
• 8000-9999Gi / 500-48000 IOPS
• 10000-12000Gi / 1000-48000 IOPS

하드 디스크

IOPS 대 기가바이트 비율은 프로비저닝되는 하드 디스크의 유형을 결정합니다. IOPS 대 기가바이트 비율을 결정하려면 IOPS를 스토리지의 크기로 나누십시오.

예: 100 IOPS의 500Gi 스토리지를 선택했습니다. 비율은 0.2(100 IOPS/500Gi)입니다.

비율별 하드 디스크 유형의 개요:

• 0.3 이하: SATA
• 0.3 초과: SSD

재확보 정책

ibmc-block-custom: 삭제

ibmc-block-retain-custom: 유지

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

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

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

토폴로지 인식 볼륨 스케줄링을 사용하려면 IBM Cloud Block Storage 플러그인 버전 1.2.0 이상을 설치했는지 확인하십시오.

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

내구성 블록 스토리지의 예.

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

성능 블록 스토리지의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-performance-storageclass
  labels:
  kubernetes.io/cluster-service: "true"
  provisioner: ibm.io/ibmc-block
  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

구역 및 지역 지정

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

IBM Cloud Block Storage 플러그인 버전 1.0.0을 사용하거나 특정 구역에서 정적으로 블록 스토리지를 프로비저닝하려는 경우에는 사용자 정의된 스토리지 클래스를 사용하십시오. 그 외의 모든 경우에는 PVC에 구역을 직접 지정하십시오.

다음의 .yaml 파일은 ibm-block-silver 비-보유(non-retaining) 스토리지 클래스를 기반으로 하는 스토리지 클래스를 사용자 정의합니다. 여기서 type은 "Endurance"이고, iopsPerGB는 4이며, sizeRange는 "[20-12000]Gi"이고, reclaimPolicy는 "Delete"로 설정됩니다. 구역은 dal12로서 지정됩니다. 다른 스토리지 클래스를 자신의 기반으로 사용하려면 스토리지 클래스 참조를 참조하십시오.

클러스터 및 작업자 노드와 동일한 지역 및 구역에 스토리지 클래스를 작성하십시오. 클러스터의 지역을 가져오려면 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>를 실행하십시오.

내구성 블록 스토리지의 예.

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

성능 블록 스토리지의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-block-performance-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-block
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Performance"
  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]"
reclaimPolicy: "Delete"

XFS 파일 시스템에서 블록 스토리지 마운트

다음 예제에서는 XFS 파일 시스템에서 블록 스토리지를 프로비저닝하는 스토리지 클래스를 작성합니다.

내구성 블록 스토리지의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
labels:
  addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  fsType: "xfs"
reclaimPolicy: "Delete"

성능 블록 스토리지의 예.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  classVersion: "2"
  type: "Performance"
  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]
  fsType: "xfs"
reclaimPolicy: "Delete"

스토리지 제거 옵션 이해

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 block volume-list --columns id --columns notes | grep <pv_name>
    

    출력 예

    12345678   {"plugin":"ibmcloud-block-storage-plugin-689df949d6-4n9qg","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"block-storage-pvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-block-silver","reclaim":"Delete"}
    

    참고 필드 정보 이해:

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

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

    "region":"us-south"

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

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

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

    "type":"Endurance"

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

    "ns":"default"

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

    "pvc":"block-storage-pvc"

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

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

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

    "storageclass":"ibmc-file-gold"

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

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

    ibmcloud sl block volume-cancel <classic_block_id>
    

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

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

ibmcloud sl block volume-list