- 印刷する
- PDF
ブロックストレージCSIのご利用ガイド
- 印刷する
- PDF
当該コンテンツは、ローカリゼーションサービスを準備しております。早急にローカライズサービスをご提供できるよう、努めております。
Classic環境で利用できます。
ご利用の前に
全てのコンテナーは、ビルドの時点で追加されたファイルを利用して駆動されます。その後、コンテナーのファイルシステム内に新しく追加されたファイルは、プロセスが終了したり、Kubernetesのliveness Probeのステータスチェックに失敗し、コンテナーが再起動される場合に全て削除されます。
コンテナーが再起動される場合でも、上述した追加されたファイルを継続して維持させることを希望するなら、配布の際に作ることのできるPersistentVolumeClaim
(PVC)を通じてデータの保存のために作ることができる永久なリポジトリであるブロックストレージを利用することができます。
NAVERクラウドプラットフォームのNcloud Kubernetes Serviceは、ボリュームドライバーとして、Container Storage Interface(CSI)を提供します。このボリュームドライバーは、Kubernetesと連携され、ブロックストレージの生成と削除及びattaching、detachingのような作業をサポートします。
制限事項
対応バージョン
NAVERクラウドプラットフォームのKubernetes Serviceは、ブロックストレージのボリュームドライバーとしてCSIを提供します。CSIドライバーとKubernetesとの間の連携のためには、互換性のあるバージョンを確認する必要があります。
現在、NAVERクラウドプラットフォームから提供しているCSIバージョンと互換性のあるKubernetesバージョンは、次の通りです。
Ncloud CSI Driver\Kubernetes Version | 1.12 | 1.17 |
---|---|---|
v0.4.x | yes | no |
v2.0.x | no | yes |
Kubernetesバージョンに対応するストレージサービスは、次の通りです。
Service\Kubernetes Version | 1.12 | 1.17 |
---|---|---|
ボリュームの生成 | 対応 | 対応 |
ボリュームの削除 | 対応 | 対応 |
ボリュームの拡張 | 未対応 | 未対応 |
サーバにボリュームの割り当て | 対応 | 対応 |
サーバにボリューム解除 | 対応 | 対応 |
snapshotの作成 | 対応 | 対応 |
snapshotの削除 | 対応 | 対応 |
Kubernetes 1.12バージョンのCSIにおいては、ボリュームの拡張機能がスペックに存在しないため提供されておりません。そのバージョンのKubernetesでボリュームの拡張のためには、手動での作業が求められるため、PVCの作成の際に適したサイズのボリュームを設定する必要があります。
割り当て可能な容量
CSIを通じて割り当てられるブロックストレージのサイズは次の通りであり、10GB単位で割り当てが可能です。
10GB未満のボリュームサイズをリクエストした場合、最小サイズである10GBで作られます。必要なボリュームサイズを定義しない場合、基本値の20GBでリクエストされます。
- 最小: 10GB
- 最大: 2000GB
CSIを始める(従来の未インストールクラスター用)
この節は、Container Storage Interface(CSI)をKubernetesのクラスターにインストールする方法について説明します。CSIが既にインストールされている場合には、以下の作業を行わなくても問題ありません。
要求事項
- Kubernetesのクラスターバージョンと互換性のあるCSIドライバーの配布
- 各ワーカーノードのkubeletに
--allow-privileged
のフラグ(flag)をtrueに設定 - 各ワーカーノードのkubeletに
--feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true
値のfeature gateフラグ(flag)を設定
NAVERクラウドプラットフォームのKubernetes Serviceのワーカーノードでkubeletのための環境変数ファイルは、/etc/kubernetes/kubelet.envにあります。このファイル内のKUBELET_FEATURE_GATES
変数にCSIのためのfeature gateを追加する。
KubernetesのクラスターにCSI Driverを配布する
認証のためのトークンを獲得する
認証トークンを発行するために、以下のページに移動します。
トークンの発行のためには認証キーが必要です。認証キーは、ポータル>マイページ>認証キーの管理にて確認することができます。
- トークンの発行ページの上段のAuthorizeをクリックします。
- ポータルから発行された認証キーをAccess Key、Secret Keyフィールドに入力します。API Keyフィールドは開けておきます。入力後に下のAuthorizeをクリックします。認証キーが入力されたことを確認した後、Doneをクリックします。
- 認証キーを入力した後、/auth/token/issue項目をクリックします。次の画面でTry it outをクリックします。
- 下の
"endpoint"
のkeyに該当するvalueにKubernetes Serviceで駆動中のクラスターのendpointを入力します。endpoint値は、Kubernetes Serviceのページで駆動中のクラスター項目をクリックすると、確認することができます。 - endpointを入力した後、Executeをクリックします。作業に成功したら、下のResponseで発行されたトークンを確認することができます。
- 発行されたトークンが有効か否かは、/auth/token/validate項目から確認することできます。
CSI Driverを配布する
- 発行されたトークンで
Secret
を作ります。
下のSecret
の例のaccess-token
keyのvalueに発行されたトークンを入力し、secret.yml
という名前で保存します。
apiVersion: v1
kind: Secret
metadata:
name: nks-access-token
namespace: kube-system
stringData:
access-token: "eyJhbGciO__REPLACE_ME____f9hJtQa4rb7A"
保存したファイルとkubectl
コマンドでSecret
を作ります。
$ kubectl --kubeconfig=$KUBE_CONFIG create -f ./secret.yml
secret "nks-access-token" created
Namespace kube-system
に作られたSecert
を確認することができます。
$ kubectl --kubeconfig=$KUBE_CONFIG get secrets -n kube-system
NAME TYPE DATA AGE
nks-access-token Opaque 1 1m
CSIドライバー及びSidecarを配布する
- CSIドライバー及びSidecarを配布します。運用されているKubernetes Clusterと互換性のあるバージョンのCSIドライバーを配布しなければなりません。互換性のあるバージョンのリストは、制限事項にて確認することができます。
k8s 1.12 バージョンから配布
kubernetes 1.12バージョンは、CSI v0.4と互換性があります。
$ kubectl --kubeconfig=$KUBE_CONFIG apply -f http://nks-static.ncloud.com:8443/csi/0.4/latest/csi-nks-configmap.yaml
$ kubectl --kubeconfig=$KUBE_CONFIG apply -f http://nks-static.ncloud.com:8443/csi/0.4/latest/csi-nks-driver.yaml
k8s 1.17 バージョンから配布
kubernetes 1.17バージョンは、CSI v2.0と互換性があります。
$ kubectl --kubeconfig=$KUBE_CONFIG apply -f http://nks-static.ncloud.com:8443/csi/0.4/latest/csi-nks-configmap.yaml
$ kubectl --kubeconfig=$KUBE_CONFIG apply -f https://nks.apigw.ntruss.com/static/v1/csi/classic/2.0/latest/csi-nks-driver.yaml
このファイルは、最新の安定バージョンを指します。インストール過程で問題が生じた場合、kubectl apply -f
コマンドを再度実行して漏れたresourceが再度反映されるようにします。
CSI Driver Object
Kubernetesのクラスターは、永続データ(Persistent data)を読み取り及び書き込み作業が必要な場合、CSIドライバーを用いてブロックストレージをコンテナーにマウントすることができます。必要なストレージサイズをPersistentVolumeClaim
(PVC)を通じてリクエストすることができます。CSIドライバーは、作られたPVCを確認し、ブロックストレージを作った後で割り当てをリクエストしたコンテナーをマウントさせます。
Storage Class
KubernetesにおいてStorageClass
は、性能及び目的に応じて多様なストレージを抽象化した概念です。それを通じて、各ストレージに対して任意のポリシーやタイプなどを設定することができます。NAVERクラウドプラットフォームでは、ブロックストレージを利用する基本的なStorageClassを提供します。
Namespace kube-system
内のStorageClassでnks-block-storage
という名前のobjectを確認することができます。
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: nks-block-storage
namespace: kube-system
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: blk.csi.ncloud.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
parameters:
type: SSD
① Default Storage Classは、annotationのstorageclass.kubernetes.io/is-default-class
値を true
で有します。別の値かannotationがない場合、false
で適用されます。
② volumeBindingMode
値を通じてボリュームバインドと動的プロビジョニング(Dynamic Provisioning)がある時点で動作するかを制御することができます。定義されていなければ、基本値としてImmediate
を有します。
PersistentVolumeClaim
を通じて設定によって必要の度に自動でPersistentVolume
を作ることができます。それを動的プロビジョニング(Dynamic Provisioning)と言います。
Mode | Description |
---|---|
Immediate | ボリュームバインドと動的プロビジョニング(provisioning)とのPVCの作られる時点で動作します。 |
WaitForFirstConsumer | ボリュームバインドと動的プロビジョニング(provisioning)とがPVCを利用するPodが作られる際に動作します。 |
③ reclaimPolicy
を通じて、利用が 終了したPVCが削除される際、使用中のPersistentVolume
(PV)に対する再確保(Reclaim)ポリシーを設定することができます。定義されていなければ、基本値はDelete
です。
Policy | Description |
---|---|
Retain | PVCが削除されると、利用中のPVは再利用が可能な状態に変更されます。ストレージ内部のデータはそのまま維持されます。 |
Delete | PVCが削除されると、利用中のPVも削除します。連携されていたブロックストレージも返却されます。 |
動的プロビジョニング(Dynamic Provisioning)で作られたブロックストレージが自動的に返却されることを防止するためには、再確保ポリシーであるreclaimPolicy
をRetain
に設定する必要があります。この場合、PersistentVolumeClaim
が削除されても、ブロックストレージは一緒に返却されず、存在する間は料金が請求されます。このブロックストレージは、コンソールやAPIを利用して手動で返却しなければなりません。
④ parametersのtypeを通じて作られるブロックストレージのタイプを選択することができます。SSD
とHDD
のうち何れか一方を使用します。定義されていなければ、基本値はSSD
です。
Type | Description |
---|---|
SSD | ストレージタイプで高性能のI/OをサポートするSSDを利用します。素早いデータの処理が必要な場合に適しています。 |
HDD | ストレージタイプとしてHDDを利用します。 |
⑤ 如果allowVolumeExpansion字段为true,则可以扩展PVC(PersistentVolumeClaim)。
作られたStorageClass Objectの内容を修正するためには、以下の文書をご参照ください。
Changing the default StorageClass
CSI Controller
ボリュームの生成、削除、割り当て、割り当て解除、snapshotなどのコントロールと管理とを担当します。Namespace kube-system
内のstatefulsetで確認することができます。
$ kubectl --kubeconfig=$KUBE_CONFIG get statefulset -n kube-system
NAME DESIRED CURRENT AGE
csi-nks-controller 1 1 37d
CSI Node
Kubernetesのワーカーノード毎に1つずつ動作しており、ボリュームのフォーマット、マウント、アンマウントなどの動作を担当します。Namespace kube-system
内のdaemonsetで確認することができます。
$ kubectl --kubeconfig=$KUBE_CONFIG get daemonset -n kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
csi-nks-node 3 3 3 3 3 <none> 44d
CSIを利用したブロックストレージを割り当て
PersistentVolumeClaim
必要なPersistentVolume
(PV) resourceは、PersistentVolumeClaim
(PVC)を通じてリクエストすることができます。CSI Driverは、PVCを確認し、必要なPersistentVolume
(PV)を自動的に作ります。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-pod-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: nks-block-storage
AccessMode
NAVERクラウドプラットフォームのブロックストレージに対応するAccessModeは、次の通りです。
- ReadWriteOnce: 単一ノードがボリュームを読み取り/書き込みできるようにマウントされることができます。
その他に、AccessModeで色んなノードによる読み取り専用でマウントするReadOnlyMany
と、色んなノードによる読み取り/書き込みモードでマウンドするReadWriteMany
とがあります。NAVERクラウドプラットフォームのブロックストレージは、このAccessModeに対応していません。
Resources
必要なストレージのサイズを入力します。入力しなければ20GB値が基本値として利用されます。ストレージサイズは、10GB単位で入力することができ、最小10GBから最大2000GBまでの間の値が許容されます。
Podに単一の新規ボリュームを割り当て
新しいブロックストレージを1つ作り、それをボリュームでマウントします。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-pod-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: nks-block-storage
---
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-volume
command: [ "sleep", "1000000" ]
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: csi-pod-pvc
Pod
Podのspec.volumes
にコンテナーとバインドされるストレージを定義することができます。配列の要素で入力し、ストレージ名と作られたPVC名をpersistentVolumeClaim
のclaimName
に入力します。
コンテナーで定義されたストレージをマウントすることができます。spec.container
でPersistentVolume
が必要なコンテナーがあれば、volumeMounts
に定義されたストレージ名を入力します。マウントされるパスは、mountPath
に入力します。
既に作られたブロックストレージをPodにマウント
本方式は、ユーザーがPersistentVolumeClaim
(PVC)を作り、必要なストレージのボリューム自動生成をリクエストする方式ではなく、既に作られているブロックストレージを利用してPersistentVolume
(PV)を作る機能です。
既に作られているブロックストレージのInstance IDを利用し、PersistentVolume
(PV)を作ります。
kind: PersistentVolume
apiVersion: v1
metadata:
name: volume-existing-01
annotations:
pv.kubernetes.io/provisioned-by: blk.csi.ncloud.com # ブロックストレージと連携されるprovisoner名
spec:
storageClassName: nks-block-storage # ブロックストレージのストレージクラス名
persistentVolumeReclaimPolicy: Retain
capacity:
storage: 10Gi # ブロックストレージサイズ
accessModes:
- ReadWriteOnce
csi:
driver: blk.csi.ncloud.com
fsType: ext4
volumeHandle: "952814" # Block Storage Instance ID
volumeAttributes:
blk.csi.ncloud.com/noformat: "true" # ブロックストレージをフォーマットしない
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-pod-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: nks-block-storage
volumeName: "volume-existing-01"
---
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-volume
command: [ "sleep", "1000000" ]
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: csi-pod-pvc
PersistentVolume
既に存在するブロックストレージをKubernetesのクラスターで利用するためには、PersistentVolume
を作る際に、その情報を入力します。
storageClassName
にNAVERクラウドプラットフォームのストレージクラスであるnks-block-storage
を入力します。capacity.storage
に既に存在するブロックストレージのサイズを入力します。accessModes
にReadWriteOnce
を入力します。ブロックストレージをサポートするストレージクラスは当該設定のみに対応します。csi
のdriver
にストレージクラスドライバー名であるblk.csi.ncloud.com
を入力します。csi
のvolumeHandle
に作られているブロックストレージのInstance IDを入力します。csi
のvolumeAttributes
にblk.csi.ncloud.com/noformat: "true"
を入力します。その設定は、フォーマットを行わないという意味であり、従来に保存された内容を維持した状態でマウントします。
PersistentVolumeClaim
作られたPersistentVolume
(PV)とバインドされるPersistentVolumeClaim
(PVC)を作ります。
resources
のstorage
に既に存在するブロックストレージのサイズを入力します。storageClassName
にブロックストレージクラス名であるnks-block-storage
を入力します。volumeName
に作られたPersistentVolume
(PV)名を入力します。
Pod
Podを作る際、ボリュームリクエストであるPersistentVolumeClaim
(PVC)を指定し、利用するボリュームをマウントします。
spec
のvolumes
要素として使うclaimName
を入力します。
Kubernetesでは、Deployment、Statefulset、DaemonSet、ReplicaSet、Jobのようなコントローラが管理していないPodは終了しても再び作られません。このようなPodがあれば、kubectl drain
コマンドはそれを保護するために動作しません。kubectl drain
コマンドを--force
オプションを通じて実行する場合、このようなPodはクラスターから削除されます。
ボリュームの割り当て追加の例
Podに複数のボリュームを割り当て
2つの新規のブロックストレージを作り、Podにマウントします。生成のリクエストするボリュームに対して、それぞれPersistentVolumeClaim
を作成します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-pod-1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: nks-block-storage
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-pod-2
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: nks-block-storage
---
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-csi-app
image: busybox
volumeMounts:
- mountPath: "/data/pod-1/"
name: my-volume-1
- mountPath: "/data/pod-2/"
name: my-volume-2
command: [ "sleep", "1000000" ]
volumes:
- name: my-volume-1
persistentVolumeClaim:
claimName: csi-pod-1
- name: my-volume-2
persistentVolumeClaim:
claimName: csi-pod-2
DeploymentでPersistentVolumeを利用する
PersistentVolumeClaim
(PVC)を作り、新規のボリューム生成をリクエストします。Deployment
のtemplate
でclaimName
を明示することで、作られたボリュームをマウントすることができます。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-deployment-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: nks-block-storage
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-csi-app
spec:
selector:
matchLabels:
app: my-csi-app
replicas: 1
template:
metadata:
labels:
app: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-volume
command: [ "sleep", "1000000" ]
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: csi-deployment-pvc
StatefulsetでPersistentVolumeを利用する
Statefulset
では、volumeClaimTemplates
を定義し、各replica
毎に新しいPersistentVolumeClaim
(PVC)を自動的に作ることができます。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-csi-app
spec:
selector:
matchLabels:
app: my-csi-app
replicas: 1
template:
metadata:
labels:
app: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-volume
command: [ "sleep", "1000000" ]
volumeClaimTemplates:
- metadata:
name: my-volume
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10Gi
CSIを利用してSnapshotの作成及びボリュームの復旧
ボリュームSnapshotを作成する
VolumeSnapshot
は、CSIで定義したユーザー指定のresource(Custom Resource Definition、CRD)です。詳しい内容は、下のリンクをご参照ください。
PersistentVolume
(PV)とバインドされているPersistentVolumeClaim
(PVC)を利用して、VolumeSnapshot
を作成します。
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
name: csi-nks-test-snapshot # 新規作成されるVolumeSnapShotが利用する名前を入力
spec:
source:
name: csi-pod-pvc # Snapshotを作成するPVとバインドされているPVC名を入力
kind: PersistentVolumeClaim
metadata
のname
に新しく作成されるVolumeSnapShotが利用する名前を入力します。spec
のsource.name
にsnapshotを作成するPVとバインドされているPVC名を入力します。spec
のsource.kind
には、PersistentVolumeClaim
を入力します。
作成されたボリュームsnapshotを確認する
作成されたボリュームsnapshotを確認するために、次のkubectl
コマンドを利用します。
ボリュームsnapshotのresource名は、VolumeSnapShot
です。
$ kubectl --kubeconfig=$KUBE_CONFIG get volumesnapshot
NAME AGE
csi-nks-test-snapshot 17h
作成されたボリュームsnapshotを削除する
作成されたボリュームsnapshotを確認するために、次のkubectl
コマンドを利用します。
削除するボリュームsnapshot名を利用して当該resourceを削除します。
$ kubectl --kubeconfig=$KUBE_CONFIG get volumesnapshot
NAME AGE
csi-nks-test-snapshot 17h
$ kubectl --kubeconfig=$KUBE_CONFIG delete volumesnapshot csi-nks-test-snapshot
volumesnapshot.snapshot.storage.k8s.io "csi-nks-test-snapshot" deleted
作成されたボリュームsnapshotからボリュームを復旧する
ボリュームsnapshotを利用し、新規のボリュームを作ることをリクエストします。作成されたsnapshotの内容が新規のボリュームとしてコピーされます。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: csi-nks-test-pvc-restore
spec:
dataSource:
name: csi-nks-test-snapshot # 復旧するボリュームsnapshot名
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: nks-block-storage
---
kind: Pod
apiVersion: v1
metadata:
name: csi-restore-app
spec:
containers:
- name: my-frontend
image: busybox
volumeMounts:
- mountPath: "/data"
name: my-volume
command: [ "sleep", "1000000" ]
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: csi-nks-test-pvc-restore
PersistentVolumeClaim
ボリュームsnapshotからボリュームを復旧するためには、spec.dataSource
に対象情報を入力します。
dataSource.name
に復旧するボリュームsnapshot名を入力します。dataSource.kind
に復旧対象のresource名であるVolumeSnapshot
を入力します。dataSource.apiGroup
にsnapshotのapiGroupであるsnapshot.storage.k8s.io
を入力します。resources.requests.storage
にボリュームsnapshotのサイズと同じ値を入力します。
Pod
リクエストしたボリューム情報であるPersistentVolumeClaim
(PVC)名にclaimName
を入力します。
PersistentVolumeClaimを削除する
Kubernetesにおいては、PersistentVolumeClaim
(PVC)はリクエストされたDeployment、StatefulSet、ReplicaSet、Podのようなresourceを削除するとしても一緒に削除されません。
次のコマンドを利用し、PersistentVolumeClaim
(PVC)を削除することができます。
# pvcの照会
$ kubectl --kubeconfig=$KUBE_CONFIG get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
csi-pod-pvc Bound pvc-084a811bac4211e9842bf220cd 10Gi RWO nks-block-storage 2m8s
# pvcの削除
$ kubectl --kubeconfig=$KUBE_CONFIG delete pvc csi-pod-pvc
persistentvolumeclaim "csi-pod-pvc" deleted