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) を使用して、マネージド ディスクを作成します。 Kubernetes バージョン 1.29 以降、複数の可用性ゾーンにデプロイされた Azure Kubernetes Service (AKS) クラスターでは、このストレージ クラスは Azure Standard SSD ゾーン冗長ストレージ (ZRS) を利用してマネージド ディスクを作成します。managed-csi-premium
:Azure Premium LRS を使用してマネージド ディスクを作成します。 Kubernetes バージョン 1.29 以降、複数の可用性ゾーンにデプロイされた Azure Kubernetes Service (AKS) クラスターでは、このストレージ クラスは Azure Premium ゾーン冗長ストレージ (ZRS) を利用してマネージド ディスクを作成します。
両方のストレージ クラスの再利用ポリシーによって、それぞれの 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 のディスク ベース ソリューションに関する記事を参照してください。
Azure Kubernetes Service