IBM Cloud Kubernetes ServiceでStorageClassを使った動的プロビジョニングを行う

# 目的

KubernetesはPersistentVolumeClaimでStorageClassを指定することでPersistentVolumeの動的プロビジョニングを行うことができますが、そのためにはストレージ側の対応が必要になるといった環境面での制約があります。IBM Cloud Kubernetes Servicesはさすがにパブリッククラウドだけあって、クラウドのストレージサービスとの連携にももちろん対応しています。

というわけで、StorageClassを使った動的プロビジョニングを試してみます。

> https://console.bluemix.net/docs/containers/cs_storage_file.html#file_storage

# 手順

## 組み込みStorageClassの確認

まずは確認。

```
$ kubectl get storageclasses
NAME                         PROVISIONER        AGE
default                      ibm.io/ibmc-file   1h
ibmc-file-bronze (default)   ibm.io/ibmc-file   1h
ibmc-file-custom             ibm.io/ibmc-file   1h
ibmc-file-gold               ibm.io/ibmc-file   1h
ibmc-file-retain-bronze      ibm.io/ibmc-file   1h
ibmc-file-retain-custom      ibm.io/ibmc-file   1h
ibmc-file-retain-gold        ibm.io/ibmc-file   1h
ibmc-file-retain-silver      ibm.io/ibmc-file   1h
ibmc-file-silver             ibm.io/ibmc-file   1h
```

プラン別にStorageClassが用意されています。retainが付くものはReclaimPolicyがRetain、付かないものはDeleteになっています。

詳細を見てみます。

```
$ kubectl describe sc ibmc-file-bronze
Name:            ibmc-file-bronze
IsDefaultClass:  Yes
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass
","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"ibmc-file-bronze","namespace":"
"},"parameters":{"billingType":"hourly","classVersion":"2","iopsPerGB":"2","sizeRange":"[20-12000]Gi","type":"Endurance"
},"provisioner":"ibm.io/ibmc-file","reclaimPolicy":"Delete"}
,storageclass.kubernetes.io/is-default-class=true
Provisioner:           ibm.io/ibmc-file
Parameters:            billingType=hourly,classVersion=2,iopsPerGB=2,sizeRange=[20-12000]Gi,type=Endurance
AllowVolumeExpansion:  <unset>
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>
```

## PVCの作成

PersistentVolumeClaimを作成します。オーダーは最低20GBからです。

```pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: teruq-pvc
  annotations:
    volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 20Gi
```

しばらく（数分？）待つとBoundになります。

```
$ kubectl apply -f pvc.yaml
persistentvolumeclaim/teruq-pvc created

$ kubectl get pvc
NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS       AGE
teruq-pvc   Pending                                      ibmc-file-bronze   9s

$ kubectl get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
teruq-pvc   Bound    pvc-707efff2-d77c-11e8-8ced-763e5a181f99   20Gi       RWX            ibmc-file-bronze   2m
```

ポータルからIBM Cloud File Storageを確認します。対応するストレージが作られていることがわかります。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/241424/3f1d1d18-f6a8-4a93-971a-566387cc42c9.png)

## PVCの削除

PVCを消します。

```
$ kubectl delete -f pvc.yaml
```

しばらく待つと、ポータルでストレージに削除マークがつきます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/241424/1dcec5ae-4146-8329-fa2a-b4170df3c13a.png)

クラウドとしては当たり前なんですが、当たり前のことが出来てうれしいです。

# 参考）PVCの削除とFile Storageの関係

* ReclaimPolicyがDeleteの場合、PVCを削除するとFile Storageの許可ホストからIKSのアドレスが削除される（誰もアクセスできない状態になる）、そしてしばらく待つと削除される
* ReclaimPolicyがRetainの場合、PVCを削除してもFile Storageは残る、許可ホストもIKSのアドレスが設定されたままになる（つまり、手動での削除をしないと残り続けて課金される）