Azure Kubernetes Service (AKS) で Azure Disk の Container Storage Interface (CSI) ドライバーを使用する

Azure Disk の Container Storage Interface (CSI) ドライバーは、Azure Disk のライフサイクルを管理するために Azure Kubernetes Service (AKS) によって使用される CSI 仕様準拠のドライバーです。

CSI は、Kubernetes のコンテナー化されたワークロードに任意のブロックおよびファイル ストレージ システムを公開する標準です。 CSI を採用および使用すると、AKS が Kubernetes で新しいストレージ システムを公開したり、既存のストレージ システムを改良したりするプラグインを記述、デプロイ、反復処理できるようになります。 AKS で CSI ドライバーを使用すると、Kubernetes のコア コードに触れたり、そのリリース サイクルを待ったりする必要がなくなります。

CSI ドライバーがサポートされる AKS クラスターを作成するには、AKS で CSI ドライバーを有効にする方法に関する記事を参照してください。 この記事では、Azure Disk CSI ドライバー バージョン 1 を使用する方法について説明します。

注意

Azure Disk CSI ドライバー v2 (プレビュー) により、スケーラビリティが向上し、ポッドのフェールオーバー待機時間が短縮します。 共有ディスクを使用して、複数のクラスター ノードに接続レプリカをプロビジョニングし、ポッド スケジューラと統合して、ポッド フェールオーバー時に接続レプリカを持つノードが選択されるようになっています。 Azure Disk CSI ドライバー v2 (プレビュー) は、パフォーマンスを微調整する機能も備えています。 プレビューへの参加に関心がある場合は、要求 https://aka.ms/DiskCSIv2Preview を送信してください。 このプレビュー バージョンは、サービス レベル アグリーメントなしで提供されます。プレビュー中に、破壊的変更が行われることがあります。 プレビュー バージョンは運用環境のワークロードには推奨されません。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。

Note

"ツリー内ドライバー" とは、プラグインの新しい CSI ドライバーに対し、コア Kubernetes コードの一部である現在のストレージ ドライバーを指します。

Azure Disk CSI ドライバーの機能

インツリー ドライバー機能に加えて、Azure Disk CSI ドライバーでは、次の機能がサポートされています。

• 同時ディスク アタッチおよびデタッチ時のパフォーマンスの向上
  • インツリー ドライバーではディスクがシリアルでアタッチまたはデタッチされますが、CSI ドライバーではディスクがバッチでアタッチまたはデタッチされます。 1 つのノードに多数のディスクをアタッチする場合に、大幅な向上が見られます。
• Premium SSD v1 と v2 がサポートされています。
  • PremiumV2_LRS は None キャッシュ モードのみをサポートします
• ゾーン冗長ストレージ (ZRS) ディスクのサポート:
  • ディスクの種類として Premium_ZRS と StandardSSD_ZRS がサポートされています。 ZRS ディスクはゾーンまたはゾーン以外のノードでスケジュールできます。ディスク ボリュームを特定のノードと同じゾーンに併置する必要があるという制限はありません。 サポートされているリージョンなどの詳細については、マネージド ディスクのゾーン冗長ストレージに関する記事を参照してください。
• スナップショット
• ボリュームの複製
• ダウンタイムが発生しないディスク PV のサイズ変更

注意

使用される VM SKU によっては、Azure Disk CSI ドライバーにノードごとのボリューム制限がある場合があります。 一部の強力な VM (16 コアなど) の場合、制限はノードあたり 64 ボリュームです。 VM SKU あたりの制限を特定するには、提供される VM SKU ごとの [最大データ ディスク数] 列を確認します。 提供される VM SKU とそれに対応する詳細な容量制限の一覧については、「汎用仮想マシンのサイズ」を参照してください。

Azure Disk を含む CSI 永続ボリュームを使用する

永続ボリューム (PV) とは、Kubernetes ポッドで使用するためにプロビジョニングされているストレージの一部です。 PV は 1 つまたは複数のポッドで使用でき、動的または静的にプロビジョニングできます。 この記事では、AKS クラスター内の単一のポッドによって使用するために Azure Disk の PV を動的に作成する方法を説明します。 静的プロビジョニングについては、Azure Disk を使用する静的ボリュームの作成に関する記事を参照してください。

Kubernetes ボリュームの詳細については、AKS でのアプリケーションのストレージ オプションに関するページを参照してください。

組み込みのストレージ クラスを使用して Azure Disk の PV を動的に作成する

ストレージ クラスは、保存の単位を永続ボリュームを使用して動的に作成する方法を定義します。 Kubernetes ストレージ クラスの詳細については、Kubernetes ストレージ クラスに関する記事を参照してください。

AKS で Azure Disk CSI ドライバーを使用する場合は、Azure Disk CSI ストレージ ドライバーを使用する組み込み StorageClasses が 2 つ追加されています。 他の CSI ストレージ クラスは、ツリー内の既定のストレージ クラスと共にクラスターで作成されます。

• managed-csi:Azure Standard SSD ローカル冗長ストレージ (LRS) を使用して、マネージド ディスクを作成します。
• managed-csi-premium:Azure Premium LRS を使用してマネージド ディスクを作成します。

両方のストレージ クラスの再利用ポリシーによって、それぞれの PV が削除されると、基になる Azure Disk が削除されます。 ストレージ クラスでは、PV は拡張可能なようにも構成されます。 ユーザーは、新しいサイズで永続ボリューム要求 (PVC) を編集することだけが必要です。

これらのストレージ クラスを使用するには、PVC とそれらを参照して使用するポッドを作成します。 PVC を使用して、ストレージ クラスに基づいてストレージを自動的にプロビジョニングします。 PVC は、事前に作成されたいずれかのストレージ クラスまたはユーザー定義のストレージ クラスを使用して、目的の SKU とサイズの Azure マネージド ディスクを作成できます。 ポッド定義を作成するとき、必要なストレージを要求するために PVC が指定されます。

kubectl apply コマンドを実行して、サンプルのポッドとそれぞれの PVC を作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/pvc-azuredisk-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/nginx-pod-azuredisk.yaml

コマンドの出力は、次の例のようになります。

persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created

ポッドが実行中状態になったら、次のコマンドを実行して、test.txt という新しいファイルを作成します。

kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt

ディスクが正しくマウントされていることを検証するには、次のコマンドを実行して、出力に test.txt ファイルが表示されることを確認します。

kubectl exec nginx-azuredisk -- ls /mnt/azuredisk

lost+found
outfile
test.txt

カスタム ストレージ クラスを作成する

既定のストレージ クラスはほとんどの一般的なシナリオに適合します。 場合によっては、独自のストレージ クラスを独自のパラメーターを使用してカスタマイズすることもできます。 たとえば、volumeBindingMode クラスを変更したい場合があります。

PVC が作成された直後に発生することを保証する volumeBindingMode: Immediate クラスを使用できます。 ノード プールがトポロジに制約されている場合 (たとえば、可用性ゾーンを使用している場合)、PV は、ポッドのスケジューリング要件を認識しないでバインドまたはプロビジョニングされます。

このシナリオに対処するには、volumeBindingMode: WaitForFirstConsumer を使用できます。これにより、PV のバインドとプロビジョニングは、PVC を使用するポッドが作成されるまで遅延されます。 このように、PV は、ポッドのスケジューリング制約によって指定された可用性ゾーン (または他のトポロジ) に準拠し、その中にプロビジョニングされます。 既定のストレージ クラスでは、volumeBindingMode: WaitForFirstConsumer クラスが使用されます。

sc-azuredisk-csi-waitforfirstconsumer.yaml という名前のファイルを作成し、次のマニフェストを貼り付けます。 ストレージ クラスは managed-csi ストレージ クラスと同じですが、volumeBindingMode クラスは異なります。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

kubectl apply コマンドを実行してストレージ クラスを作成し、sc-azuredisk-csi-waitforfirstconsumer.yaml ファイルを指定します。

kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml

コマンドの出力は、次の例のようになります。

storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created

ボリューム スナップショット

Azure Disk の CSI ドライバーでは、永続ボリューム スナップショットの作成がサポートされています。 この機能の一部として、ドライバーでは、incremental パラメーターに設定されている値 (既定では true) に応じて、"完全" または "増分" スナップショットのいずれかを実行できます。

次の表に、すべてのパラメーターの詳細を示します。

Name	意味	使用できる値	Mandatory	既定値
resourceGroup	スナップショット ショットを格納するためのリソース グループ	既存のリソース グループ	いいえ	指定しない場合、スナップショットはソース Azure Disk と同じリソース グループに格納されます
インクリメンタル	完全または増分スナップショットを作成します	true、 false	いいえ	true
tags	Azure Disk タグ	タグの形式: 'key1=val1,key2=val2'	いいえ	""
userAgent	顧客の使用状況属性に使用されるユーザー エージェント		いいえ	driverName/driverVersion compiler/version (OS-ARCH) の形式の生成された Useragent
subscriptionID	Azure Disk が作成される Azure サブスクリプション ID を指定します	Azure サブスクリプション ID	いいえ	空でない場合は、resourceGroup を指定する必要があり、incremental を false として設定する必要があります

ボリューム スナップショットを作成する

注意

先に進む前に、アプリケーションがソース ディスクにデータを書き込んでいないことを確認します。

この機能の例として、kubectl apply コマンドを使用してボリューム スナップショット クラスを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/storageclass-azuredisk-snapshot.yaml

コマンドの出力は、次の例のようになります。

volumesnapshotclass.snapshot.storage.k8s.io/csi-azuredisk-vsc created

次に、このチュートリアルの始めに動的に作成した PVC (pvc-azuredisk) から、ボリューム スナップショットを作成しましょう。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/azuredisk-volume-snapshot.yaml

コマンドの出力は、次の例のようになります。

volumesnapshot.snapshot.storage.k8s.io/azuredisk-volume-snapshot created

スナップショットが正しく作成されたことを確認するには、次のコマンドを実行します。

kubectl describe volumesnapshot azuredisk-volume-snapshot

コマンドの出力は、次の例のようになります。

Name:         azuredisk-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T05:27:58Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  714582
  Self Link:         /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
  UID:               dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azuredisk
  Volume Snapshot Class Name:      csi-azuredisk-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
  Creation Time:                       2020-08-31T05:27:59Z
  Ready To Use:                        true
  Restore Size:                        10Gi
Events:                                <none>

ボリューム スナップショットを基にして新しい PVC を作成する

ボリューム スナップショットを基にして新しい PVC を作成することができます。 前のステップで作成したスナップショットを使用して、新しい PVC と、それを使用する新しいポッドを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/pvc-azuredisk-snapshot-restored.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/nginx-pod-restored-snapshot.yaml

コマンドの出力は、次の例のようになります。

persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created

最後に、次のコマンドを実行して内容を調べることにより、前に作成したものと同じ PVC であることを確認します。

kubectl exec nginx-restored -- ls /mnt/azuredisk

コマンドの出力は、次の例のようになります。

lost+found
outfile
test.txt

予想どおり、前に作成した test.txt ファイルをまだ見ることができます。

ボリュームを複製する

複製されたボリュームは、既存の Kubernetes ボリュームの複製として定義されます。 Kubernetes でのボリュームの複製の詳細については、ボリュームの複製に関する概念ドキュメントを参照してください。

Azure Disk 用の CSI ドライバーでは、ボリュームの複製がサポートされています。 デモンストレーションのため、前に作成したazuredisk-pvc のクローンされたボリュームと、それを使用するための新しいポッドを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/pvc-azuredisk-cloning.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/nginx-pod-restored-cloning.yaml

コマンドの出力は、次の例のようになります。

persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created

次のコマンドを実行し、ファイル test.txt が作成されていることを確認することで、クローンされたボリュームの内容を確認できます。

kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk

コマンドの出力は、次の例のようになります。

lost+found
outfile
test.txt

ダウンタイムなしで永続ボリュームのサイズを変更する

PVC で大きいボリュームを要求できます。 PVC オブジェクトを編集し、より大きいサイズを指定します。 この変更により、PV の基になるボリュームの拡張がトリガーされます。

注意

要求を満たすために新しい PV が作成されることはありません。 代わりに、既存のボリュームのサイズが変更されます。

AKS では、組み込みの managed-csi ストレージ クラスは既に拡張をサポートしているので、このストレージ クラスで前に作成した PVC を使用します。 PVC では、10 Gi の永続ボリュームが要求されました。 次のコマンドを実行して確認できます。

kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

コマンドの出力は、次の例のようになります。

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk

次のコマンドを実行して spec.resources.requests.storage フィールドを増やして PVC を展開します。

kubectl patch pvc pvc-azuredisk --type merge --patch '{"spec": {"resources": {"requests": {"storage": "15Gi"}}}}'

注意

永続ボリュームの圧縮は現在サポートされていません。 現在の PVC よりも小さいサイズの既存の PVC にパッチを適用しようとすると、次のエラー メッセージが表示されます。The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

コマンドの出力は、次の例のようになります。

persistentvolumeclaim/pvc-azuredisk patched

次のコマンドを実行して、ボリューム サイズが増加したことを確認します。

kubectl get pv

コマンドの出力は、次の例のようになります。

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
(...)

さらに数分後、次のコマンドを実行して、PVC のサイズを確認します。

kubectl get pvc pvc-azuredisk

コマンドの出力は、次の例のようになります。

NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            managed-csi    2d2h

次のコマンドを実行して、ポッド内のディスクのサイズを確認します。

kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

コマンドの出力は、次の例のようになります。

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         15G   46M   15G   1% /mnt/azuredisk

オンデマンド バースト

オンデマンドのディスク バースト モデルにより、ディスクのニーズが現在の容量を超えるたびに、ディスクがバーストします。 このモデルでは、ディスクがバーストするたびに追加料金が発生します。 オンデマンド バーストは 512 GiB より大きい Premium SSD でのみ使用できます。 Premium SSD のプロビジョニング済みの IOPS とディスクあたりのスループットの詳細については、「Premium SSD のサイズ」を参照してください。 または、クレジットベースのバーストでは、クレジット バケットにバースト クレジットが累積されている場合にのみ、ディスクがバーストします。 クレジット ベースのバーストでは、ディスク バースト時に追加料金は発生しません。 クレジットベースのバーストは、512 GiB 以下のPremium SSD と 1024 GiB 以下の Standard SSD でのみ使用できます。 オンデマンド バーストの詳細については、「オンデマンド バースト」を参照してください。

重要

既定の managed-csi-premium ストレージ クラスでは、オンデマンド バーストが無効になっており、クレジット ベースのバーストが使用されます。 既定の managed-csi-premium ストレージ クラスに基づいた永続ボリューム要求によって動的に作成された Premium SSD もオンデマンド バーストが無効になっています。

オンデマンド バーストが有効な Premium SSD 永続ボリュームを作成するには、次の YAML テンプレートに示すように enableBursting パラメーターを true に設定して新しいストレージ クラスを作成できます。 オンデマンド バーストの有効化の詳細については、「オンデマンド バースト」を参照してください。 オンデマンド バーストが有効な独自のストレージ クラスの構築の詳細については、「バースト可能なマネージド CSI Premium Storage クラスの作成」を参照してください。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Windows コンテナー

Azure Disk CSI ドライバーでは、Windows のノードとコンテナーがサポートされています。 Windows コンテナーを使用する場合は、Windows コンテナーのクイックスタートに従って、Windows ノード プールを追加してください。

Windows ノード プールを追加した後は、managed-csi などの組み込みストレージ クラスを使用できます。 次の kubectl apply コマンドを実行して、タイムスタンプをファイル data.txt に保存するサンプル Windows ベースのステートフル セットをデプロイできます。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/windows/statefulset.yaml

コマンドの出力は、次の例のようになります。

statefulset.apps/busybox-azuredisk created

ボリュームの内容を検証するには、次のコマンドを実行します。

kubectl exec -it busybox-azuredisk-0 -- cat c:\\mnt\\azuredisk\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azuredisk-0 -- cat c:\mnt\azuredisk\data.txt # on Windows Powershell/CMD

コマンドの出力は、次の例のようになります。

2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)

次のステップ

• Azure Files で CSI ドライバーを使用する方法を確認するには、CSI ドライバーでの Azure Files の使用に関するページを参照してください。
• Azure Blob Storage に CSI ドライバーを使用する方法については、「CSI ドライバーで Azure Blob Storage を使用する」を参照してください
• ストレージのベスト プラクティスの詳細については、「Azure Kubernetes Service のストレージとバックアップに関するベスト プラクティス」を参照してください。
• ディスクベースのストレージ ソリューションの詳細については、AKS のディスク ベース ソリューションに関する記事を参照してください。