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

[アーティクル]
08/07/2024

Azure Files の Container Storage Interface (CSI) ドライバーは、Azure ファイル共有のライフサイクルを管理するために Azure Kubernetes Service (AKS) によって使用される CSI 仕様準拠のドライバーです。 CSI は、Kubernetes のコンテナー化されたワークロードに任意のブロックおよびファイルストレージシステムを公開する標準です。

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

CSI ドライバーがサポートされる AKS クラスターを作成するには、AKS で CSI ドライバーを有効にする方法に関する記事を参照してください。

注意

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

Azure Files CSI ドライバーの新機能

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

バージョン 4.1 の Network File System (NFS)
プライベートエンドポイント
ファイル共有の大規模なマウントの並列作成。

Azure Files を使用した永続ボリュームを使用する

永続ボリューム (PV)とは、Kubernetes ポッドで使用するためにプロビジョニングされているストレージの一部です。 PV は 1 つまたは複数のポッドで使用でき、動的または静的にプロビジョニングできます。複数のポッドが同じストレージボリュームに同時アクセスする必要がある場合は、Azure Files を使用し、サーバーメッセージブロック (SMB) または NFS プロトコルを使用して接続できます。この記事では、AKS クラスターの複数のポッドで使用するために、Azure Files 共有を動的に作成する方法を示します。静的プロビジョニングの場合は、Azure Files 共有を含むボリュームを手動で作成して使用するに関する記事を参照してください。

Note

Azure File CSI ドライバーでは、キーベース (NTLM v2) 認証を使用した SMB ファイル共有のマウントのみが許可されるため、Azure ファイル共有設定の最大セキュリティプロファイルはサポートされないことに注意してください。一方、NFS ファイル共有をマウントする場合、キーベースの認証は必要ありません。

Azure Files 共有では、ノードにマウントできる数に関する制限はありません。

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

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

ストレージクラスを使用して、Azure ファイル共有を作成する方法を定義します。ストレージアカウントは、ストレージクラスと共に使用して Azure ファイル共有を保持するために、ノードリソースグループ内に自動的に作成されます。 skuName には、次のいずれかの Azure Storage の冗長性 SKU を選択します。

Standard_LRS:標準のローカル冗長ストレージ
Standard_GRS:標準の geo 冗長ストレージ
Standard_ZRS:標準のゾーン冗長ストレージ
Standard_RAGRS:標準の読み取りアクセス geo 冗長ストレージ
Standard_RAGRS: 標準の読み取りアクセス geo ゾーン冗長ストレージ
Premium_LRS:Premium ローカル冗長ストレージ
Premium_ZRS:Premium ゾーン冗長ストレージ

Note

Azure Files は Azure Premium ファイル共有をサポートします。ファイル共有の最小容量は 100 GiB です。 Standard ファイル共有ではなく Azure Premium ファイル共有を使うことをお勧めします。その理由は、I/O 集中型ワークロードに対して、Premium ファイル共有の方が高いパフォーマンスと低待機時間のディスクサポートを提供するからです。

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

azurefile-csi: Azure Standard Storage を使用して Azure ファイル共有を作成します。
azurefile-csi-premium: Azure Premium Storage を使用して Azure ファイル共有を作成します。

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

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

kubectl apply コマンドを実行することで、現在の日付を outfile に出力する PVC とポッドの例を作成します。

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

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

persistentvolumeclaim/pvc-azurefile created
pod/nginx-azurefile created

ポッドが実行中の状態になったら、次のコマンドを実行して、出力に outfile が含まれていることを確認することによって、ファイル共有が正しくマウントされていることを検証できます。

kubectl exec nginx-azurefile -- ls -l /mnt/azurefile

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

total 29
-rwxrwxrwx 1 root root 29348 Aug 31 21:59 outfile

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

既定のストレージクラスは最も一般的なシナリオに適合しますが、すべてに適合するわけではありません。場合によっては、独自のストレージクラスを独自のパラメーターを使用してカスタマイズすることもできます。たとえば、次のマニフェストを使用して、ファイル共有の mountOptions を構成します。

Kubernetes でマウントされたファイル共有の場合、fileMode と dirMode の既定値は 0777 です。ストレージクラスオブジェクトでは、さまざまなマウントオプションを指定できます。

azure-file-sc.yaml という名前のファイルを作成し、次のマニフェストの例を貼り付けます。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0640
  - file_mode=0640
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict # https://linux.die.net/man/8/mount.cifs
  - nosharesock
parameters:
  skuName: Standard_LRS

kubectl apply コマンドを実行することで、ストレージクラスを作成します。

kubectl apply -f azure-file-sc.yaml

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

storageclass.storage.k8s.io/my-azurefile created

Azure Files の CSI ドライバーでは、永続ボリュームおよび基になるファイル共有のスナップショットの作成がサポートされています。

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

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

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

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

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

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

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

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

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

kubectl describe volumesnapshot azurefile-volume-snapshot

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

Name:         azurefile-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1beta1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T22:37:41Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  955091
  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-volume-snapshot
  UID:               c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azurefile
  Volume Snapshot Class Name:      csi-azurefile-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
  Ready To Use:                        false
Events:                                <none>

永続ボリュームのサイズを変更する

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

注意

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

永続ボリュームの圧縮は現在サポートされていません。

AKS では、組み込みの azurefile-csi ストレージクラスは既に拡張をサポートしているので、このストレージクラスで前に作成した PVC を使用します。この PVC は 100 GiB のファイル共有を要求しています。これを確認するには、次のコマンドを実行します。

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

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

Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  100G  128K  100G   1% /mnt/azurefile

spec.resources.requests.storage フィールドを増やして、PVC を拡張します。

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

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

persistentvolumeclaim/pvc-azurefile patched

PVC とポッド内のファイルシステムの両方に新しいサイズが表示されることを確認します。

kubectl get pvc pvc-azurefile
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
pvc-azurefile   Bound    pvc-5e5d9980-da38-492b-8581-17e3cad01770   200Gi      RWX            azurefile-csi   64m

kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  200G  128K  200G   1% /mnt/azurefile

プライベート Azure Files ストレージ (プライベートエンドポイント) で永続ボリュームを使用する

Azure Files リソースがプライベートエンドポイントで保護されている場合は、独自のストレージクラスを作成する必要があります。プライベートエンドポイントの IP アドレスが接続文字列の FQDN に解決されるように DNS 設定を構成していることを確認します。次のパラメーターをカスタマイズします。

resourceGroup: ストレージアカウントが配置されているリソースグループ。
storageAccount: ストレージアカウントの名前。
server: ストレージアカウントのプライベートエンドポイントの FQDN。

private-azure-file-sc.yaml という名前のファイルを作成し、次のマニフェストの例をそのファイルに貼り付けます。 <resourceGroup> および <storageAccountName> の値を置き換えます。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: private-azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  resourceGroup: <resourceGroup>
  storageAccount: <storageAccountName>
  server: <storageAccountName>.file.core.windows.net
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload

kubectl apply コマンドを使用して、ストレージクラスを作成します。

kubectl apply -f private-azure-file-sc.yaml

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

storageclass.storage.k8s.io/private-azurefile-csi created

private-pvc.yaml という名前のファイルを作成し、次のマニフェストの例をそのファイルに貼り付けます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: private-azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: private-azurefile-csi
  resources:
    requests:
      storage: 100Gi

kubectl apply コマンドを使用して、PVC を作成します。

kubectl apply -f private-pvc.yaml

NFS ファイル共有

Azure Files では、NFS v4.1 プロトコルがサポートされています。 Azure Files での NFS バージョン 4.1 のサポートによって、サービスとしてのフルマネージド NFS ファイルシステムがお客様に提供されます。これは、可用性が高く耐久性に優れた、分散型で回復力のあるストレージプラットフォーム上に構築されています。

このオプションは、インプレースデータ更新を使用するランダムアクセスワークロードに合わせて最適化されており、完全な POSIX ファイルシステムのサポートを提供します。このセクションでは、AKS クラスター上で NFS 共有を Azure File CSI ドライバーと共に使用する方法について説明します。

前提条件

AKS クラスター "コントロールプレーン" ID (お使いの AKS クラスター名) が、VNet および NetworkSecurityGroup の共同作成者ロールに追加されます。
AKS クラスターのサービスプリンシパルまたはマネージドサービス ID (MSI) を、ストレージアカウントの共同作成者ロールに追加する必要があります。

Note

選択した VNet へのアクセスを許可する代わりに、プライベートエンドポイントを使用できます。

読み取りおよび書き込みのサイズオプションの最適化

このセクションでは、"rsize" および "wsize" オプションによる、Azure Files CSI ドライバーを使用した NFS のパフォーマンスチューニングに取り組む方法について説明します。 rsize および wsize オプションは、NFS 操作の最大転送サイズを設定します。マウント時に rsize や wsize が指定されていない場合、クライアントとサーバーでは、その 2 つでサポートされる最大サイズをネゴシエートします。現在、Azure NetApp Files と最新の Linux ディストリビューションの両方で、1,048,576 バイト (1 MiB) の読み取りおよび書き込みサイズがサポートされています。

最適なパフォーマンスは、効率的なクライアントとサーバーの通信に基づいています。 マウントの読み取りおよび書き込みオプションのサイズ値を増減すると、NFS のパフォーマンスを向上させることができます。クライアントとサーバーの間で転送される読み取り/書き込みパケットの既定のサイズは、NFS バージョン 2 では 8 KB、NFS バージョン 3 と 4 では 32 KB です。これらの既定値は、大きすぎるか小さすぎる可能性があります。 rsize および wsize を減らすと、NFS の読み取り応答および書き込み要求ごとに、より小さなパケットを送信することで、混雑したネットワークでの NFS パフォーマンスが向上する可能性があります。ただし、これにより、ネットワーク経由でデータを送信するために必要なパケットの数が増え、クライアントとサーバーのネットワークトラフィックと CPU 使用率の合計が増加する可能性があります。

効率的なパケット転送 (スループットが低下せず、待機時間が長くならない) を維持する rsize と wsize を見つけるために、テストを実行することが重要です。

rsize と wsize の最適化の詳細については、Azure NetApp Files 用の Linux NFS マウントオプションのベストプラクティスに関する記事を参照してください。

たとえば、"rsize" と "wsize" の最大サイズを 256 KiB に構成するには、ストレージクラスで mountOptions を次のように構成します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30
  - rsize=262144
  - wsize=262144

nfs-sc.yaml という名前のファイルを作成し、以下のマニフェストをコピーします。サポートされている mountOptions の一覧については、「NFS マウントオプション」を参照してください。

Note

vers、minorversion、sec は、Azure File CSI ドライバーが構成されます。これらのプロパティのマニフェストでの値の指定はサポートされていません。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

ファイルを編集して保存した後、kubectl apply コマンドを使用してストレージクラスを作成します。

kubectl apply -f nfs-sc.yaml

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

storageclass.storage.k8s.io/azurefile-csi-nfs created

kubectl apply コマンドを使用して、タイムスタンプをファイル data.txt に保存するサンプル ステートフルセットをデプロイできます。

kubectl apply -f

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-azurefile
  labels:
    app: nginx
spec:
  podManagementPolicy: Parallel  # default is OrderedReady
  serviceName: statefulset-azurefile
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
        - name: statefulset-azurefile
          image: mcr.microsoft.com/oss/nginx/nginx:1.19.5
          command:
            - "/bin/bash"
            - "-c"
            - set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done
          volumeMounts:
            - name: persistent-storage
              mountPath: /mnt/azurefile
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  volumeClaimTemplates:
    - metadata:
        name: persistent-storage
      spec:
        storageClassName: azurefile-csi-nfs
        accessModes: ["ReadWriteMany"]
        resources:
          requests:
            storage: 100Gi

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

statefulset.apps/statefulset-azurefile created

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

kubectl exec -it statefulset-azurefile-0 -- df -h

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

Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
accountname.file.core.windows.net:/accountname/pvc-fa72ec43-ae64-42e4-a8a2-556606f5da38  100G     0  100G   0% /mnt/azurefile
...

Note

NFS ファイル共有は Premium アカウントにあるため、ファイル共有の最小サイズは 100 GiB であることに注意してください。ストレージサイズが小さい PVC を作成すると、"ファイル共有を作成できませんでした...サイズ (5)..." というエラーが発生する場合があります。

Windows コンテナー

Azure Files の CSI ドライバーは、Windows のノードとコンテナーもサポートしています。 Windows コンテナーを使用するには、Windows コンテナーのクイックスタートに従って、Windows ノードプールを追加します。

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

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

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

statefulset.apps/busybox-azurefile created

次の kubectl exec コマンドを実行することで、ボリュームの内容を検証します。

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

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

2020-08-27 22:11:01Z
2020-08-27 22:11:02Z
2020-08-27 22:11:04Z
(...)

次の手順

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

次の方法で共有

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

Azure Files CSI ドライバーの新機能

Azure Files を使用した永続ボリュームを使用する

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

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

永続ボリュームのサイズを変更する

プライベート Azure Files ストレージ (プライベートエンドポイント) で永続ボリュームを使用する

NFS ファイル共有

前提条件

読み取りおよび書き込みのサイズオプションの最適化

Windows コンテナー

次の手順

その他のリソース

次の方法で共有

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

Azure Files CSI ドライバーの新機能

Azure Files を使用した永続ボリュームを使用する

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

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

永続ボリュームのサイズを変更する

プライベート Azure Files ストレージ (プライベートエンドポイント) で永続ボリュームを使用する

NFS ファイル共有

前提条件

読み取りおよび書き込みのサイズ オプションの最適化

NFS ファイル共有のストレージ クラスを作成する

NFS でサポートされるファイル共有を使用してデプロイを作成する

Windows コンテナー

次の手順

その他のリソース

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

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

読み取りおよび書き込みのサイズオプションの最適化

NFS ファイル共有のストレージクラスを作成する