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

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 ドライバーでは、次の新機能がサポートされています。

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

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

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 でマウントされたファイル共有の場合、fileModedirMode の既定値は 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 ドライバーでは、永続ボリュームおよび基になるファイル共有のスナップショットの作成がサポートされています。

注意

このドライバーは、スナップショットの作成のみをサポートしています。スナップショットからの復元は、このドライバーではサポートされていません。 スナップショットは、Azure portal または CLI から復元できます。 スナップショットの作成と復元の詳細については、「Azure Files の共有スナップショットの概要」を参照してください。

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 ファイル共有のストレージ クラスを作成する

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

Note

versminorversionsec は、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

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

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
(...)

次の手順