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

永続ボリュームとは、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 のカスタム ストレージ クラスを定義するために使用できるパラメータが含まれています。

ストレージ クラスの作成

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

• 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)

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

1. 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
   

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

   kubectl apply -f azure-file-sc.yaml
   

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

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

1. azure-file-pvc.yaml という名前のファイルを作成し、そこに以下の YAML をコピーします。 storageClassName が前の手順で作成したストレージ クラスと一致していることを確認します。

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

   Note

   ストレージ クラスに Premium_LRS SKU を使用する場合、storage の最小値は 100Gi である必要があります。

2. 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 コンテナーの場合、 'D:' などの Windows パス規則を使用して mountPath を指定します。

1. 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
   

2. 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

Azure タグの使用

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

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

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

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

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

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

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

1. az aks show コマンドを --query nodeResourceGroup パラメーターと共に使用してリソース グループ名を取得します。

   az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
   

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

   MC_myResourceGroup_myAKSCluster_eastus
   

2. 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
   

3. 次のコマンドを使用して、接続文字列を環境変数としてエクスポートします。これは、ファイル共有の作成に使用します。

   export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string -n storageAccountName -g resourceGroupName -o tsv)
   

4. az storage share create コマンドを使用してファイル共有を作成します。 必ず shareName を共有名に置き換えてください。

   az storage share create -n shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
   

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

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

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

   echo Storage account key: $STORAGE_KEY
   

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

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

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

   kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=myAKSStorageAccount --from-literal=azurestorageaccountkey=$STORAGE_KEY
   

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

1. 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
   

2. kubectl create コマンドを使用して永続ボリュームを作成します。

   kubectl create -f azurefiles-pv.yaml
   

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

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

4. kubectl apply コマンドを使用して PersistentVolumeClaim を作成します。

   kubectl apply -f azurefiles-mount-options-pvc.yaml
   

5. kubectl get コマンドを使用して、PersistentVolumeClaim が作成され、PersistentVolume にバインドされていることを確認します。

   kubectl get pvc azurefile
   

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

   NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
   

6. YAML ファイルでコンテナーの指定を更新して、PersistentVolumeClaim とポッドを参照するようにします。 次に例を示します。

   ...
     volumes:
     - name: azure
       persistentVolumeClaim:
         claimName: azurefile
   

7. ポッドの仕様はインプレースで更新できないため、kubectl delete コマンドを使用してポッドを削除し、kubectl apply コマンドを使用して再作成します。

   kubectl delete pod mypod
   
   kubectl apply -f azure-files-pod.yaml
   

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

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

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

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

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

   kubectl apply -f azure-files-pod.yaml
   

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

   kubectl describe pod mypod
   

次のステップ

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

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