Azure Kubernetes Service (AKS) で Azure Files を使用してボリュームを作成して使用する

2025-05-06

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

この記事で取り上げるテクニック:

動的永続ボリューム (PV) を使用するには、Container Storage Interface (CSI) ドライバーをインストールし、1 つ以上の Azure ファイル共有を動的に作成してポッドにアタッチします。
静的 PV を使用するには、1 つ以上の Azure ファイル共有を作成するか、既存のものを使い、それをポッドにアタッチします。

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

開始する前に

Azure ストレージアカウントが必要です。
Azure CLI バージョン 2.0.59 以降がインストールされ、構成されていることを確認してください。バージョンを確認するには、az --version を実行します。インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。
Standard ファイル共有と Premium ファイル共有のどちらかを選択する場合は、Azure Files で実行する予定の、期待される使用パターンのプロビジョニングモデルと要件を理解しておくことが重要です。詳細については、使用パターンに基づいた Azure Files パフォーマンスレベルの選択に関するページを参照してください。

ボリュームを動的にプロビジョニングする

このセクションでは、Azure Files 上の 1 つ以上の共有の詳細など、1 つ以上の永続ボリュームをプロビジョニングするクラスター管理者向けのガイダンスを提供します。永続ボリューム要求 (PVC) は、ストレージクラスオブジェクトを使って、Azure Files ファイル共有を動的にプロビジョニングします。

動的 PersistentVolumes のストレージクラスパラメータ

次の表には、PersistentVolumeClaim のカスタムストレージクラスを定義するために使用できるパラメータが含まれています。

名前	意味	使用できる値	必須	規定値
accountAccessTier	ストレージアカウントのアクセス層	Standard アカウントでは `Hot` または `Cool` を選択でき、Premium アカウントでは `Premium` のみを選択できます。	いいえ	空白。ストレージアカウントの種類ごとに既定の設定を使用します。
accountQuota	アカウントのクォータを制限します。最大クォータは GB で指定できます (既定では 102,400 GB)。指定されたクォータをアカウントが超えた場合、ドライバーはアカウントの選択をスキップします。		いいえ	`102400`
BLOBの公開アクセスを許可	ドライバーによって作成されたストレージアカウントのすべての BLOB またはコンテナーへのパブリックアクセスを許可または禁止します。	`true` または `false`	いいえ	`false`
削除保持ポリシーを無効にする	ドライバーによって作成されたストレージアカウントの DeleteRetentionPolicy を無効にするかどうかを指定します。	`true` または `false`	いいえ	`false`
フォルダ名	Azure ファイル共有内のフォルダー名を指定します。	Azure ファイル共有内の既存のフォルダー名。	いいえ	フォルダー名がファイル共有に存在しない場合、マウントは失敗します。
最新のアカウントを取得	作成日時に基づいて最新のアカウントキーを取得するかどうかを決定します。このドライバーを使うと、既定で最初のキーを取得します。	`true` または `false`	いいえ	`false`
ロケーション	Azure ストレージアカウントの Azure リージョンを指定します。	たとえば、「 `eastus` 」のように入力します。	いいえ	空の場合、ドライバーでは、現在の AKS クラスターと同じ場所の名前を使用します。
matchTags	ドライバーが適切なストレージアカウントを検索しようとしたときにタグを照合します。	`true` または `false`	いいえ	`false`
ネットワークエンドポイントタイプ	ドライバーによって作成されたストレージアカウントのネットワークエンドポイントの種類を指定します。 `privateEndpoint` が指定されている場合、ストレージアカウントのプライベートエンドポイントが作成されます。それ以外の場合は、既定でサービスエンドポイントが作成されます。	""、`privateEndpoint`	いいえ	""
プロトコル	ファイル共有プロトコルを指定します。	`smb`、`nfs`	いいえ	`smb`
インフラ暗号化を要求する	ドライバーによって作成されたストレージアカウントの保存データに、プラットフォームマネージドキーを使用した暗号化のセカンダリレイヤーをサービスで適用するかどうかを指定します。	`true` または `false`	いいえ	`false`
resourceGroup	Azure Disks のリソースグループを指定します。	既存のリソースグループ名	いいえ	空の場合、ドライバーでは、現在の AKS クラスターと同じリソースグループ名を使用します。
ランダムに一致するアカウントを選択	一致するアカウントをランダムに選択するかどうかを決定します。既定では、ドライバーを使うと必ず、最初に一致するアカウントがアルファベット順に選択されます (注: このドライバーでは、アカウント検索キャッシュを使っており、その結果、複数のアカウント間でファイルの作成が不均等に分散されます)。	`true` または `false`	いいえ	`false`
サーバー	Azure ストレージアカウントのサーバーアドレスを指定します。	既存のサーバーアドレス (`accountname.privatelink.file.core.windows.net` など)。	いいえ	空の場合、ドライバーでは、既定の `accountname.file.core.windows.net` またはその他のソブリンクラウドのアカウントアドレスを使用します。
shareAccessTier	ファイル共有のアクセス層	汎用の v2 アカウントでは、`TransactionOptimized` (既定値)、`Hot`、`Cool` のいずれかを選択できます。ファイル共有専用の Premium タイプのストレージアカウント。	いいえ	空白。ストレージアカウントの種類ごとに既定の設定を使用します。
shareName	Azure ファイル共有名を指定します。	既存または新規の Azure ファイル共有名。	いいえ	空の場合、ドライバーでは Azure ファイル共有名を生成します。
shareNamePrefix	ドライバーによって作成された Azure ファイル共有名のプレフィックスを指定します。	共有名には小文字、数字、ハイフンのみを含めることができ、長さは 21 文字未満にする必要があります。	いいえ
skuName	Azure Files ストレージアカウントの種類 (別名: `storageAccountType`)	`Standard_LRS`、`Standard_ZRS`、`Standard_GRS`、`Standard_RAGRS`、`Standard_RAGZRS`、`Premium_LRS`、`Premium_ZRS`	いいえ	`Standard_LRS` Premium アカウントの種類でのファイル共有の最小サイズは 100 GB です。 ZRS アカウントの種類は、制限されたリージョンでサポートされています。 NFS ファイル共有では、Premium アカウントの種類のみがサポートされています。
ストレージアカウント	Azure ストレージアカウントの名前を指定します。	ストレージアカウント名	いいえ -	特定のストレージアカウント名が指定されていない場合、ドライバーは、同じリソースグループ内のアカウント設定と一致する適切なストレージアカウントを探します。一致するストレージアカウントが見つからない場合は、新規作成されます。ただし、ストレージアカウント名が指定される場合は、そのストレージアカウントが既に存在している必要があります。
ストレージエンドポイントサフィックス	Azure Storage エンドポイントサフィックスを指定します。	`core.windows.net`、`core.chinacloudapi.cn` などです。	いいえ	空の場合、ドライバーでは、クラウド環境に応じて既定のストレージエンドポイントサフィックスを使用します。たとえば、「 `core.windows.net` 」のように入力します。
タグ	タグは、新しいストレージアカウントに作成されます。	タグの形式: 'foo=aaa,bar=bbb'	いいえ	""
---	次のパラメーターは SMB プロトコル専用です	---	---
サブスクリプションID	Azure ファイル共有が作成される Azure サブスクリプション ID を指定します。	Azure サブスクリプション ID	いいえ	空でない場合は、`resourceGroup` を指定する必要があります。
ストアアカウントキー	アカウントキーを Kubernetes シークレットに格納するかどうかを指定します。	`true` または `false` `false` は、ドライバーが kubelet ID を使用してアカウントキーを取得することを意味します。	いいえ	`true`
シークレット名	アカウントキーを格納するシークレット名を指定します。		いいえ
secretNamespace	アカウントキーを格納するシークレットの名前空間を指定します。注: `secretNamespace` が指定されていない場合、シークレットはポッドと同じ名前空間内に作成されます。	`default`、`kube-system`など	いいえ	PVC 名前空間 (`csi.storage.k8s.io/pvc/namespace` など)
useDataPlaneAPI	ファイル共有の作成/削除/サイズ変更にデータプレーン API を使用するかどうかを指定します。データプレーン API には制限がほとんどないため、これによって SRP API のスロットリングの問題が解決する可能性がありますが、ストレージアカウントにファイアウォールまたは VNet 設定がある場合は失敗します。	`true` または `false`	いいえ	`false`
---	次のパラメーターは NFS プロトコル専用です	---	---
マウント許可	マウントされたフォルダーのアクセス許可。既定では、 `0777`です。 `0` に設定されている場合、ドライバーでは、マウント後に `chmod` を実行しません。	`0777`	いいえ
rootSquashType	共有でのルートスカッシュの動作を指定します。既定値は `NoRootSquash` です	`AllSquash`、`NoRootSquash`、`RootSquash`	いいえ
---	次のパラメーターは VNet 設定専用です。たとえば、NFS、プライベートエンドポイント	---	---
fsGroupChangePolicy	ドライバーがボリュームの所有権を変更する方法を示します。ポッド `securityContext.fsGroupChangePolicy` は無視されます。	`OnRootMismatch` (既定値)、`Always`、`None`	いいえ	`OnRootMismatch`
サブネット名	サブネット名	エージェントノードの既存のサブネット名。	いいえ	空の場合、ドライバーには Azure クラウド構成ファイル内の `subnetName` 値が使われます。
vnetName	仮想ネットワーク名	既存の仮想ネットワーク名。	いいえ	空の場合、ドライバーはクラスター仮想ネットワークのすべてのサブネットを更新します。
vnetResourceGroup	仮想ネットワークが定義されている VNet リソースグループを指定します。	既存のリソースグループ名。	いいえ	空の場合、ドライバーには Azure クラウド構成ファイル内の `vnetResourceGroup` 値が使われます。

¹ ドライバーによってストレージアカウントが作成されている場合は、ストレージクラスで networkEndpointType: privateEndpoint パラメーターを指定するだけで済みます。 CSI ドライバーは、プライベートエンドポイントとプライベート DNS ゾーン ( privatelink.file.core.windows.net という名前) をアカウントと共に作成します。独自のストレージアカウントを使用する場合は、ストレージアカウントのプライベートエンドポイントを作成する必要があります。ネットワーク分離クラスターで Azure Files ストレージを使用している場合は、"networkEndpointType: privateEndpoint" を使用してカスタムストレージクラスを作成する必要があります。以下のサンプルを参考にしてください。

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - 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
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

ストレージクラスの作成

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

Standard_LRS: Standard ローカル冗長ストレージ (LRS)
Standard_GRS: Standard geo 冗長ストレージ (GRS)
Standard_ZRS: Standard ゾーン冗長ストレージ (ZRS)
Standard_RAGRS: Standard 読み取りアクセス geo 冗長ストレージ (RA-GRS)
Premium_LRS: Premium ローカル冗長ストレージ (LRS)
Premium_ZRS: Premium ゾーン冗長ストレージ (ZRS)

注

Premium ファイル共有の最小サイズは 100 GB です。

Azure Files 用の Kubernetes ストレージクラスの詳細については、Kubernetes ストレージクラスに関するページを参照してください。

azure-file-sc.yaml という名前のファイルを作成し、次の例のマニフェストにコピーします。 mountOptions の詳細については、「マウントオプション」セクションを参照してください。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com # replace with "kubernetes.io/azure-file" if aks version is less than 1.21
allowVolumeExpansion: true
mountOptions:
 - dir_mode=0777
 - file_mode=0777
 - uid=0
 - gid=0
 - mfsymlinks
 - cache=strict
 - actimeo=30
 - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
parameters:
  skuName: Premium_LRS

kubectl apply コマンドを使用して、ストレージクラスを作成します。
```
kubectl apply -f azure-file-sc.yaml
```

永続ボリューム要求の作成

永続ボリューム要求 (PVC) は、ストレージクラスオブジェクトを使用して、Azure ファイル共有を動的にプロビジョニングします。次の YAML を使用して、サイズが 100 GB で、ReadWriteMany アクセス権の永続ボリューム要求を作成できます。アクセスモードの詳細については、Kubernetes 永続ボリュームに関するページを参照してください。

azure-file-pvc.yaml という名前のファイルを作成し、そこに以下の YAML をコピーします。 storageClassName が前の手順で作成したストレージクラスと一致していることを確認します。
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-azurefile
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: my-azurefile
  resources:
    requests:
      storage: 100Gi
```
注

ストレージクラスに Premium_LRS SKU を使用する場合、storage の最小値は 100Gi である必要があります。
kubectl apply コマンドを使用して永続ボリューム要求を作成します。
```
kubectl apply -f azure-file-pvc.yaml
```
完了すると、ファイル共有が作成されます。接続情報と資格情報を含む Kubernetes シークレットも作成されます。 kubectl get コマンドを使用すると、PVC の状態を表示できます。
```
kubectl get pvc my-azurefile
```
コマンドの出力は、次の例のようになります。
```
NAME           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
my-azurefile   Bound     pvc-8436e62e-a0d9-11e5-8521-5a8664dc0477   100Gi       RWX            my-azurefile      5m
```

永続ボリュームの使用

次の YAML では、永続ボリューム要求 my-azurefile を使って Azure Files ファイル共有を /mnt/azure パスにマウントするポッドを作成します。 Windows Server コンテナーの場合、 mountPath などの Windows パス規則を使用してを指定します。

azure-pvc-files.yaml という名前のファイルを作成し、そこに以下の YAML をコピーします。 claimName が前の手順で作成した PVC と一致していることを確認します。

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: mypod
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      resources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 250m
          memory: 256Mi
      volumeMounts:
        - mountPath: /mnt/azure
          name: volume
          readOnly: false
  volumes:
   - name: volume
     persistentVolumeClaim:
       claimName: my-azurefile

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

kubectl apply -f azure-pvc-files.yaml

これで、/mnt/azure ディレクトリにマウントされた Azure Files ファイル共有でポッドが実行するようになります。 kubectl describe コマンドを使ってポッドを調べると、この構成を確認できます。次に示したのは、その出力例の抜粋です。コンテナーにマウントされたボリュームが表示されています。

Containers:
  mypod:
    Container ID:   docker://053bc9c0df72232d755aa040bfba8b533fa696b123876108dec400e364d2523e
    Image:          mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    Image ID:       docker-pullable://nginx@sha256:d85914d547a6c92faa39ce7058bd7529baacab7e0cd4255442b04577c4d1f424
    State:          Running
      Started:      Fri, 01 Mar 2019 23:56:16 +0000
    Ready:          True
    Mounts:
      /mnt/azure from volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-8rv4z (ro)
[...]
Volumes:
  volume:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  my-azurefile
    ReadOnly:   false
[...]

マウントオプション

Kubernetes バージョン 1.13.0 以降の場合、fileMode と dirMode の既定値は 0777 です。ストレージクラスを使って永続ボリュームを動的に作成している場合は、ストレージクラスのオブジェクトに対してマウントオプションを指定できます。詳細については、「オプションをマウントする」を参照してください。次の例では、0777 が設定されます。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com # replace with "kubernetes.io/azure-file" if aks version is less than 1.21
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
parameters:
  skuName: Premium_LRS

注

マウントオプション (mountOptions) を構成する場所は、動的永続ボリュームと静的永続ボリュームのどちらをプロビジョニングしているかによって異なります。ストレージクラスを使用してボリュームを動的にプロビジョニングする場合は、ストレージクラスオブジェクトのマウントオプション (種類: StorageClass) を指定します。ボリュームを静的にプロビジョニングする場合は、PersistentVolume オブジェクト (種類: PersistentVolume) にマウントオプションを指定します。ファイル共有をインラインボリュームとしてマウントする場合は、Pod オブジェクト (種類: Pod) にマウントオプションを指定します。

Azure タグの使用

Azure タグの使用の詳細については、「Azure Kubernetes Service (AKS) での Azure タグの使用」を参照してください。

ボリュームを静的にプロビジョニングする

このセクションでは、ワークロードで使用するための既存の Azure Files 共有の詳細など、1 つ以上の永続ボリュームを作成するクラスター管理者向けのガイダンスを提供します。

PersistentVolume の静的プロビジョニングパラメータ

次の表には、PersistentVolume を定義するために使用できるパラメータが含まれています。

名前	意味	使用できる値	必須	規定値
volumeAttributes.resourceGroup	Azure リソースグループ名を指定します。	マイリソースグループ	いいえ	空の場合、ドライバーでは、現在のクラスターと同じリソースグループ名が使われます。
volumeAttributes.storageAccount	既存の Azure ストレージアカウント名を指定します。	ストレージアカウント名	はい
volumeAttributes.shareName	Azure ファイル共有名を指定します。	ファイル共有名	はい
volumeAttributes.folderName	Azure ファイル共有内のフォルダー名を指定します。	フォルダ名	いいえ	フォルダー名がファイル共有に存在しない場合、マウントは失敗します。
volumeAttributes.protocol	ファイル共有プロトコルを指定します。	`smb`、`nfs`	いいえ	`smb`
volumeAttributes.server	Azure ストレージアカウントのサーバーアドレスを指定する	既存のサーバーアドレス (`accountname.privatelink.file.core.windows.net` など)。	いいえ	空の場合、ドライバーでは、既定の `accountname.file.core.windows.net` またはその他のソブリンクラウドのアカウントアドレスを使用します。
---	次のパラメーターは SMB プロトコル専用です	---	---	---
volumeAttributes.secretName	ストレージアカウント名とキーを格納するシークレット名を指定します。		いいえ
volumeAttributes.secretNamespace	シークレットの名前空間を指定します。	`default`、`kube-system`など	いいえ	PVC 名前空間 (`csi.storage.k8s.io/pvc/namespace`)
nodeStageSecretRef.name	ストレージアカウント名とキーを格納するシークレット名を指定します。	既存のシークレット名。	いいえ	空の場合は、ドライバーが kubelet ID を使用してアカウントキーを取得することを意味します。
nodeStageSecretRef.namespace	シークレットの名前空間を指定します。	Kubernetes 名前空間	いいえ
---	次のパラメーターは NFS プロトコル専用です	---	---	---
volumeAttributes.fsGroupChangePolicy（ボリューム属性.fsグループ変更ポリシー）	ドライバーがボリュームの所有権を変更する方法を示します。ポッド `securityContext.fsGroupChangePolicy` は無視されます。	`OnRootMismatch` (既定値)、`Always`、`None`	いいえ	`OnRootMismatch`
volumeAttributes.mountPermissions	マウントされたフォルダーのアクセス許可を指定します。既定値は `0777` です		いいえ

Azure Files ファイル共有を Kubernetes ボリュームとして使うには、その前に Azure ストレージアカウントとファイル共有を作成する必要があります。

az aks show コマンドを --query nodeResourceGroup パラメーターと共に使用してリソースグループ名を取得します。
```
az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
```
コマンドの出力は、次の例のようになります。
```
MC_myResourceGroup_myAKSCluster_eastus
```
az storage account create コマンドを --sku パラメーターと共に使用してストレージアカウントを作成します。次のコマンドでは、Standard_LRS SKU を使ってストレージアカウントが作成されます。必ず、次のプレースホルダーを置き換えてください。
- ストレージアカウントの名前を含む myAKSStorageAccount
- AKS クラスターノードがホストされているリソースグループの名前を含む nodeResourceGroupName
- リソースを作成するリージョンの名前を含む location。 AKS クラスターノードと同じリージョンである必要があります。
```
az storage account create -n myAKSStorageAccount -g nodeResourceGroupName -l location --sku Standard_LRS
```
次のコマンドを使用して、接続文字列を環境変数としてエクスポートします。これは、ファイル共有の作成に使用します。
```
export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string -n storageAccountName -g resourceGroupName -o tsv)
```
az storage share create コマンドを使用してファイル共有を作成します。必ず shareName を共有名に置き換えてください。
```
az storage share create -n shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
```

次のコマンドを使用して、ストレージアカウントキーを環境変数としてエクスポートします。

STORAGE_KEY=$(az storage account keys list --resource-group nodeResourceGroupName --account-name myAKSStorageAccount --query "[0].value" -o tsv)

次のコマンドを使用して、ストレージアカウントの名前とキーをエコーします。 Kubernetes ボリュームを作成するときにこれらの値が必要なため、この情報をコピーします。
```
echo Storage account key: $STORAGE_KEY
```

Kubernetes シークレットを作成する

Kubernetes には、前の手順で作成されたファイル共有にアクセスするための資格情報が必要です。これらの資格情報は Kubernetes シークレットに格納され、Kubernetes ポッドを作成するときにそのシークレットが参照されます。

kubectl create secret コマンドを使用してシークレットを作成します。次の例では、azure-secret という名前のシークレットを作成し、前の手順の azurestorageaccountname と azurestorageaccountkey を設定しています。既存の Azure ストレージアカウントを使用するには、アカウント名とキーを指定します。
```
kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=myAKSStorageAccount --from-literal=azurestorageaccountkey=$STORAGE_KEY
```

azurefiles-pv.yaml という名前の新規ファイルを作成して、次の内容をコピーします。 csi の下にある resourceGroup、volumeHandle、shareName を更新します。マウントオプションでは、fileMode と dirMode の既定値は 0777 です。

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: file.csi.azure.com
  name: azurefile
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: azurefile-csi
  csi:
    driver: file.csi.azure.com
    volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"  # make sure this volumeid is unique for every identical share in the cluster
    volumeAttributes:
      shareName: aksshare
    nodeStageSecretRef:
      name: azure-secret
      namespace: default
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=0
    - gid=0
    - mfsymlinks
    - cache=strict
    - nosharesock
    - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

kubectl create コマンドを使用して永続ボリュームを作成します。
```
kubectl create -f azurefiles-pv.yaml
```

azurefiles-mount-options-pvc.yaml という名前の新しいファイルを作成し、次の内容をコピーします。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefile
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi
  volumeName: azurefile
  resources:
    requests:
      storage: 5Gi

kubectl apply コマンドを使用して PersistentVolumeClaim を作成します。
```
kubectl apply -f azurefiles-mount-options-pvc.yaml
```
kubectl get コマンドを使用して、PersistentVolumeClaim が作成され、PersistentVolume にバインドされていることを確認します。
```
kubectl get pvc azurefile
```
コマンドの出力は、次の例のようになります。
```
NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
```
YAML ファイルでコンテナーの指定を更新して、PersistentVolumeClaim とポッドを参照するようにします。次に例を示します。
```
...
  volumes:
  - name: azure
    persistentVolumeClaim:
      claimName: azurefile
```
ポッドの仕様はインプレースで更新できないため、kubectl delete コマンドを使用してポッドを削除し、kubectl apply コマンドを使用して再作成します。
```
kubectl delete pod mypod

kubectl apply -f azure-files-pod.yaml
```

注

パフォーマンスの問題を回避するために、多数のポッドが同じファイル共有にアクセスしている場合は、インラインボリュームではなく永続ボリュームを使用することをお勧めします。インラインボリュームがアクセスできるのはポッドと同じ名前空間内のシークレットだけです。別のシークレットの名前空間を指定するには、永続ボリュームを使用します。

Azure Files ファイル共有をポッドにマウントするには、コンテナーの指定でボリュームを構成します。

azure-files-pod.yaml という名前の新規ファイルを作成して、次の内容をコピーします。ファイル共有またはシークレットの名前を変更した場合は、shareName と secretName を更新します。 Files 共有がポッドにマウントされているパスである mountPath を更新することもできます。 Windows Server コンテナーの場合、 mountPath などの Windows パス規則を使用してを指定します。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  nodeSelector:
    kubernetes.io/os: linux
  containers:
    - image: 'mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine'
      name: mypod
      resources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 250m
          memory: 256Mi
      volumeMounts:
        - name: azure
          mountPath: /mnt/azure
          readOnly: false
  volumes:
    - name: azure
      csi:
        driver: file.csi.azure.com
        volumeAttributes:
          secretName: azure-secret  # required
          shareName: aksshare  # required
          mountOptions: 'dir_mode=0777,file_mode=0777,cache=strict,actimeo=30,nosharesock,nobrl'  # optional

kubectl apply コマンドを使用してポッドを作成します。
```
kubectl apply -f azure-files-pod.yaml
```
これで、/mnt/azure にマウントされた Azure Files ファイル共有を使ってポッドが実行するようになりました。 kubectl describe コマンドを使用して、共有が正常にマウントされていることを確認できます。
```
kubectl describe pod mypod
```

ベストプラクティス

Azure Files で最高のエクスペリエンスを得るために、次のベストプラクティスに従ってください。

マウントオプション (mountOptions) を構成する場所は、動的永続ボリュームと静的永続ボリュームのどちらをプロビジョニングしているかによって異なります。ストレージクラスを使用してボリュームを動的にプロビジョニングする場合は、ストレージクラスオブジェクトのマウントオプション (種類: StorageClass) を指定します。ボリュームを静的にプロビジョニングする場合は、PersistentVolume オブジェクト (種類: PersistentVolume) にマウントオプションを指定します。ファイル共有をインラインボリュームとしてマウントする場合は、Pod オブジェクト (種類: Pod) にマウントオプションを指定します。
ベンチマークテストを実行する場合は、FIO をお勧めします。詳細については、ベンチマークツールとテストを参照してください。

SMB 共有

SMB 共有に推奨されるマウントオプションは、次のストレージクラスの例で提供されています。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
 skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
 - dir_mode=0777  # modify this permission if you want to enhance the security
 - file_mode=0777 # modify this permission if you want to enhance the security
 - mfsymlinks    # support symbolic links
 - cache=strict  # https://linux.die.net/man/8/mount.cifs
 - nosharesock  # reduces probability of reconnect race
 - actimeo=30  # reduces latency for metadata-heavy workload
 - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Premium (SSD) ファイル共有を使用していて、ワークロードがメタデータが多い場合は、メタデータキャッシュ機能を使用してパフォーマンスを向上させるために登録します。

詳細については、「 SMB Azure ファイル共有のパフォーマンスの向上」を参照してください。

NFS 共有

NFS 共有に推奨されるマウントオプションは、次のストレージクラスの例で提供されています。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
  protocol: nfs
  skuName: Premium_LRS     # available values: Premium_LRS, Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - nconnect=4  # improves performance by enabling multiple connections to share
  - noresvport  # improves availability
  - actimeo=30  # reduces latency for metadata-heavy workloads

読み取りスループットを向上させるために先読みサイズを増やします。
Azure Files では nconnect の最大設定 16 までの設定がサポートされていますが、nconnect=4 の最適な設定でマウントオプションを構成することをお勧めします。現時点では、nconnect の Azure Files 実装では、4 つのチャネルを超える利益はありません。

詳細については、「 NFS Azure ファイル共有のパフォーマンスの向上」を参照してください。

次のステップ

Azure File CSI ドライバーパラメーターについては、「CSI ドライバーパラメーター」を参照してください。

関連するベストプラクティスについては、AKS のストレージとバックアップに関するベストプラクティスに関する記事を参照してください。

次の方法で共有

Azure Kubernetes Service (AKS) で Azure Files を使用してボリュームを作成して使用する

開始する前に

ボリュームを動的にプロビジョニングする

動的 PersistentVolumes のストレージ クラス パラメータ

ストレージ クラスの作成

永続ボリューム要求の作成

永続ボリュームの使用

マウント オプション

Azure タグの使用

ボリュームを静的にプロビジョニングする

PersistentVolume の静的プロビジョニング パラメータ

Azure ファイル共有を作成する

Kubernetes シークレットを作成する

ファイル共有を永続ボリュームとしてマウントする

ファイル共有をインライン ボリュームとしてマウントする

ベスト プラクティス