PV(PersistentVolume) 용량 증설(Scale Up) 하기

인쇄

수정 날짜: 2020-03-26 16:40

# allowVolumeExpansion 설정 확인

증설하고자 하는 PV의 storage class에 allowVolumeExpansion 설정이 되어 있는지 확인

allowVolumeExpansion: true

$ kubectl get storageclass ibmc-block-bronze -o yaml
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: "2019-02-26T07:00:03Z"
  labels:
    app: ibmcloud-block-storage-plugin
    chart: ibmcloud-block-storage-plugin-1.5.0
    heritage: Tiller
    release: ibm-block-storage-plugin
  name: ibmc-block-bronze
  resourceVersion: "52901588"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/ibmc-block-bronze
  uid: xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
parameters:
  billingType: hourly
  classVersion: "2"
  fsType: ext4
  iopsPerGB: "2"
  sizeRange: '[20-12000]Gi'
  type: Endurance
provisioner: ibm.io/ibmc-block
reclaimPolicy: Delete
volumeBindingMode: Immediate

만일, allowVolumeExpansion 설정이 안 되어 있는 경우에는

하단부분에 설명되어 있는 설정이 없을 경우의 증설방법을 사용하시기 바랍니다.

# 증설하고자 하는 용량으로 PVC 변경

증설하고자 하는 PV의 PVC를 편집으로 연 후에 용량(200GB)을 증설하는 용량으로 변경 후 저장

spec:
...

resources:
requests:
storage: 200Gi

$ kubectl edit pvc elasticsearch-data-elasticsearch-data-2
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    ibm.io/provisioning-status: complete
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-class: ibmc-block-retain-silver
    volume.beta.kubernetes.io/storage-provisioner: ibm.io/ibmc-block
  creationTimestamp: "2019-xx-xxTxx:xx:xxZ"
  finalizers:
  - kubernetes.io/pvc-protection
  labels:
    app: elasticsearch
    component: elasticsearch
    region: jp-tok
    role: data
    zone: seo01
  name: elasticsearch-data-elasticsearch-data-2
  namespace: zcp-system
  resourceVersion: "xxxxx"
  selfLink: /api/v1/namespaces/zcp-system/persistentvolumeclaims/elasticsearch-data-elasticsearch-data-2
  uid: 1af63cb4-3997-11e9-8301-9a4341108516
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi
  storageClassName: ibmc-block-retain-silver
  volumeMode: Filesystem
  volumeName: pvc-1af63cb4-3997-11e9-8301-9a4341108516
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 200Gi
  phase: Bound

# 증설한 용량으로 변경이 되었는지 확인

- PVC 용량 확인

$ kubectl get pvc -w
NAME                                                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
elasticsearch-data-test-elasticsearch-data-test-0       Bound    pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   200Gi      RWO            ibmc-block-retain-silver   21h
elasticsearch-data-test-elasticsearch-data-test-1       Bound    pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   200Gi      RWO            ibmc-block-retain-silver   21h
elasticsearch-data-test-elasticsearch-data-test-2       Bound    pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   200Gi      RWO            ibmc-block-retain-silver   21h

elasticsearch-data-test-elasticsearch-data-test-2       Bound    pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   220Gi      RWO            ibmc-block-retain-silver   21h

- PV 용량 확인

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                                                              STORAGECLASS               REASON   AGE
pvc-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   220Gi      RWO            Retain           Bound       zcp-system/elasticsearch-data-test-elasticsearch-data-test-2       ibmc-block-retain-silver            21h

- pod에 들어가서 확인

$ kubectl exec -it elasticsearch-data-test-2 bash
[root@elasticsearch-data-test-2 elasticsearch]# df -h
Filesystem                                     Size  Used Avail Use% Mounted on
overlay                                         98G  6.1G   87G   7% /
tmpfs                                           64M     0   64M   0% /dev
tmpfs                                          7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/mapper/docker_data                         98G  6.1G   87G   7% /etc/hosts
shm                                             64M     0   64M   0% /dev/shm
/dev/mapper/3600a09803830446d463f4c454857636c  216G   60M  216G   1% /usr/share/elasticsearch/data
tmpfs                                          7.9G   12K  7.9G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                                          7.9G     0  7.9G   0% /proc/acpi
tmpfs                                          7.9G     0  7.9G   0% /proc/scsi
tmpfs                                          7.9G     0  7.9G   0% /sys/firmware

- CSP console에서 확인

아래 예는 IBM console

1. 우선 PV의 VolumeID를 확인

spec:
...
flexVolume:

...
VolumeID: "131379026"

$ kubectl get pv -o yaml pvc-b4e6876b-011c-48c1-9a9b-d84172078d8f
apiVersion: v1
kind: PersistentVolume
metadata:
# Please edit the object below. Lines beginning with a '#' will be ignored,
  annotations:
    ibm.io/dm: /dev/dm-1
    ibm.io/mountpath: /var/data/kubelet/plugins/kubernetes.io/flexvolume/ibm/ibmc-block/mounts/pvc-b4e6876b-011c-48c1-9a9b-d84172078d8f
    ibm.io/mountstatus: mounted
    ibm.io/network-storage-id: "131379026"
    ibm.io/nodename: 10.178.218.161
    pv.kubernetes.io/provisioned-by: ibm.io/ibmc-block
    volume.beta.kubernetes.io/storage-class: ibmc-block-retain-silver
  creationTimestamp: "2020-03-25T08:32:34Z"
  finalizers:
  - kubernetes.io/pv-protection
  labels:
    CapacityGb: "200"
    Datacenter: seo01
    IOPS: "4"
    StorageType: Endurance
    billingType: hourly
    failure-domain.beta.kubernetes.io/region: jp-tok
    failure-domain.beta.kubernetes.io/zone: seo01
    ibm-cloud.kubernetes.io/iaas-provider: softlayer
  name: pvc-b4e6876b-011c-48c1-9a9b-d84172078d8f
  resourceVersion: "118820860"
  selfLink: /api/v1/persistentvolumes/pvc-b4e6876b-011c-48c1-9a9b-d84172078d8f
  uid: 804748e8-8d72-4ae2-8a35-beff13292390
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 200Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: elasticsearch-data-test-elasticsearch-data-test-2
    namespace: zcp-system
    resourceVersion: "118684400"
    uid: b4e6876b-011c-48c1-9a9b-d84172078d8f
  flexVolume:
    driver: ibm/ibmc-block
    fsType: ext4
    options:
      Lun: "17"
      TargetPortal: 161.26.102.71
      VolumeID: "131379026"
      volumeName: pvc-b4e6876b-011c-48c1-9a9b-d84172078d8f
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ibmc-block-retain-silver
  volumeMode: Filesystem
status:
  phase: Bound

2. IBM console에서 변경된 용량 확인

참고페이지

https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims

=====================================================================================================================================================================

< allowVolumeExpansion 설정이 안 되어 있을 경우의 증설방법 >

# PV modify LUN

1. IBM Cloud™ 콘솔(https://cloud.ibm.com)에서 클래식 인프라(Classic Infrastructure) > Storage > Block Storage를 클릭하십시오.

2. 목록에서 LUN(Logical Unit Number)을 선택하고 조치 > LUN 수정(Mdify LUN)을 클릭하십시오.

3. GB 단위로 새 스토리지 크기를 입력하십시오.

현재 PV size보다 크게만 설정 가능하고, 최대 12,000GB(12TB)까지 증설 가능합니다.

4. 선택사항 및 새 가격을 검토하십시오.

현재 PV에 적용된 storage class를 변경할 수 있습니다.

5. 마스터 서비스 계약을 읽었습니다... 선택란을 클릭하고 주문하기를 클릭하십시오.

6. 5분 정도 후에 변경된 용량으로 적용되었는지 확인하시기 바랍니다.

위의 작업들을 하게 되면 실제 strorage는 용량이 증설되었지만,

연결해서 사용하고 있는 pod에는 예전 용량으로 표시됩니다.

해당 PV에 아래 patch를 적용하고, 연결된 pod을 재기동 하시면 증설된 용량으로 연결됩니다.

$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}'

<추가> PV와 PVC에 정의된 용량을 증설된 용량으로 표시되도록 변경하는 방법

이 방법은 kubectl get pv나 kubectl get pvc로 확인하였을 때 증설된 용량으로 보이게 하기 위해서 필요합니다.

예전 용량으로 보이셔도 상관없다면 수행하지 않으셔도 됩니다.

[PV의 Reclaim Policy가 Retain인 경우]

1. PVC Backup

해당 PV의 PVC를 backup

$ kubectl get pvc <PVC name> -o yaml > <저장하고자 하는 filename>.yaml

2. PVC yaml file 수정 <만일, Endurance의 IOPS도 변경했다면 storage-class도 변경할 것>

아래 3개의 부분을 증설된 용량으로 변경해서 저장

metadata > annotation > kubectl.kubernetes.io/last-applied-configuration

spec > resources > requests > storage

status > capacity > storage

$ vi <저장한 PVC filename>.yaml
...
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-retain-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}}
...
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: ibmc-block-retain-bronze
  volumeName: pvc-#########
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  phase: Bound
...

3. PVC Delete

$ kubectl delete pvc --force --grace-period=0 <PVC name>

4. PV 수정 <만일, Endurance의 IOPS도 변경했다면 storage-class도 변경할 것>

아래 2개의 부분을 증설된 용량으로 변경해서 저장

labels > CapacityGb

spec > capacity > storage

claimRef 부분은 삭제

$ kubectl edit pv <PV name>
...
  labels:
    CapacityGb: "30"
    Datacenter: seo01
    IOPS: "2"
    StorageType: Endurance
    billingType: hourly
...
spec:
...
  capacity:
    storage: 30Gi
...
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: test-delete
    namespace: zcp-system
    resourceVersion: "########"
    uid: #####-####
...

5. PV patch

$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}'

6. PVC create

Backup해둔 PVC yaml로 PVC생성

$ kubectl create -f <저장한 PVC filename>.yaml

[PV의 Reclaim Policy가 Delete인 경우]

<주의> 아래 순서대로가 아닌 PVC를 먼저 삭제하게 되면 Storage가 삭제됨

1. PV, PVC backup

$ kubectl get pv <PV name> -o yaml > <저장하고자 하는 filename>.yaml

$ kubectl get pvc <PVC name> -o yaml > <저장하고자 하는 filename>.yaml

2. PV yaml 수정 <만일, Endurance의 IOPS도 변경했다면 storage-class도 변경할 것>

아래 2개의 부분을 증설된 용량으로 변경해서 저장

labels > CapacityGb

spec > capacity > storage

claimRef 부분은 삭제

$ vi <저장한 PV filename>.yaml
...
  labels:
    CapacityGb: "30"
    Datacenter: seo01
    IOPS: "2"
    StorageType: Endurance
    billingType: hourly
...
spec:
...
  capacity:
    storage: 30Gi
...
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: test-delete
    namespace: zcp-system
    resourceVersion: "########"
    uid: #####-####
...

3. PVC yaml file 수정 <만일, Endurance의 IOPS도 변경했다면 storage-class도 변경할 것>

아래 3개의 부분을 증설된 용량으로 변경해서 저장

metadata > annotation > kubectl.kubernetes.io/last-applied-configuration

spec > resources > requests > storage

status > capacity > storage

$ vi <저장한 PVC filename>.yaml
...
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=k8s/prod/pvc.yaml --namespace=zcp-system --record=true","volume.beta.kubernetes.io/storage-class":"ibmc-block-bronze"},"labels":{"billingType":"monthly"},"name":"pvc-test","namespace":"zcp-system"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"30Gi"}}}}...
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: ibmc-block-bronze
  volumeName: pvc-#########
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 20Gi
  phase: Bound
...

4. PV Delete

$ kubectl delete pv --force --grace-period=0 <PV name>

# 만일 위의 명령어 실행 후에도 상태가 Terminating가 계속 된다면 아래 patch 실행
$ kubectl patch pv <pvc name> -p '{"metadata":{"finalizers":null}}'

5. PVC Delete

$ kubectl delete pvc --force --grace-period=0 <PVC name>

6. PV create

Backup해둔 PV yaml로 PV생성

$ kubectl create -f <저장한 PV filename>.yaml

7. PVC create

Backup해둔 PVC yaml로 PVC생성

$ kubectl create -f <저장한 PVC filename>.yaml

8. PV patch

$ kubectl patch pv <PV name> -p '{"metadata": {"annotations":{"ibm.io/autofix-resizefs":"true"}}}'

<참고자료>

https://cloud.ibm.com/docs/infrastructure/BlockStorage?topic=BlockStorage-expandingcapacity

온라인상담

문의하기