次の方法で共有

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

名前 意味 使用できる値 Mandatory 規定値
accountAccessTier ストレージ アカウントのアクセス層 Standard アカウントでは Hot または Cool を選択でき、Premium アカウントでは Premium のみを選択できます。 いいえ 空白。 ストレージ アカウントの種類ごとに既定の設定を使用します。
accountQuota アカウントのクォータを制限します。 最大クォータは GB で指定できます (既定では 102,400 GB)。 指定されたクォータをアカウントが超えた場合、ドライバーはアカウントの選択をスキップします。 いいえ 102400
allowBlobPublicAccess ドライバーによって作成されたストレージ アカウントのすべての BLOB またはコンテナーへのパブリック アクセスを許可または禁止します。 true または false いいえ false
disableDeleteRetentionPolicy ドライバーによって作成されたストレージ アカウントの DeleteRetentionPolicy を無効にするかどうかを指定します。 true または false いいえ false
enableLargeFileShares 大きいファイルの共有が有効になっているストレージ アカウントを使うかどうかを指定します。 このフラグが true に設定されており、かつ大きいファイルの共有が有効になっているストレージ アカウントが存在しない場合は、大きいファイルの共有が有効になっている新しいストレージ アカウントが作成されます。 Premium SKU で作成されたストレージ アカウントで largeFileShares オプションが既定で有効になっているため、このフラグは Standard SKU で使う必要があります。 true または false いいえ false
folderName Azure ファイル共有内のフォルダー名を指定します。 Azure ファイル共有内の既存のフォルダー名。 いいえ フォルダー名がファイル共有に存在しない場合、マウントは失敗します。
getLatestAccount 作成日時に基づいて最新のアカウント キーを取得するかどうかを決定します。 このドライバーを使うと、既定で最初のキーを取得します。 true または false いいえ false
location Azure ストレージ アカウントの Azure リージョンを指定します。 たとえば、「 eastus 」のように入力します。 いいえ 空の場合、ドライバーでは、現在の AKS クラスターと同じ場所の名前を使用します。
matchTags ドライバーが適切なストレージ アカウントを検索しようとしたときにタグを照合します。 true または false いいえ false
networkEndpointType ドライバーによって作成されたストレージ アカウントのネットワーク エンドポイントの種類を指定します。 privateEndpoint が指定されている場合、ストレージ アカウントのプライベート エンドポイントが作成されます。 それ以外の場合は、既定でサービス エンドポイントが作成されます。 ""、privateEndpoint いいえ ""
protocol ファイル共有プロトコルを指定します。 smb、nfs いいえ smb
requireInfraEncryption ドライバーによって作成されたストレージ アカウントの保存データに、プラットフォーム マネージド キーを使用した暗号化のセカンダリ レイヤーをサービスで適用するかどうかを指定します。 true または false いいえ false
resourceGroup Azure Disks のリソース グループを指定します。 既存のリソース グループ名 いいえ 空の場合、ドライバーでは、現在の AKS クラスターと同じリソース グループ名を使用します。
selectRandomMatchingAccount 一致するアカウントをランダムに選択するかどうかを決定します。 既定では、ドライバーを使うと必ず、最初に一致するアカウントがアルファベット順に選択されます (注: このドライバーでは、アカウント検索キャッシュを使っており、その結果、複数のアカウント間でファイルの作成が不均等に分散されます)。 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 いいえ StandardSSD_LRS
Premium アカウントの種類でのファイル共有の最小サイズは 100 GB です。
ZRS アカウントの種類は、制限されたリージョンでサポートされています。
NFS ファイル共有では、Premium アカウントの種類のみがサポートされています。
storageAccount Azure ストレージ アカウントの名前を指定します。 storageAccountName いいえ - 特定のストレージ アカウント名が指定されていない場合、ドライバーは、同じリソース グループ内のアカウント設定と一致する適切なストレージ アカウントを探します。 一致するストレージ アカウントが見つからない場合は、新規作成されます。 ただし、ストレージ アカウント名が指定される場合は、そのストレージ アカウントが既に存在している必要があります。
storageEndpointSuffix Azure Storage エンドポイント サフィックスを指定します。 core.windows.net、core.chinacloudapi.cn などです。 いいえ 空の場合、ドライバーでは、クラウド環境に応じて既定のストレージ エンドポイント サフィックスを使用します。 たとえば、「 core.windows.net 」のように入力します。
tags タグは、新しいストレージ アカウントに作成されます。 タグの形式: 'foo=aaa,bar=bbb' いいえ ""
--- 次のパラメーターは SMB プロトコル専用です --- ---
subscriptionID Azure ファイル共有が作成される Azure サブスクリプション ID を指定します。 Azure サブスクリプション ID いいえ 空でない場合は、resourceGroup を指定する必要があります。
storeAccountKey アカウント キーを Kubernetes シークレットに格納するかどうかを指定します。 true または false
false は、ドライバーが kubelet ID を使用してアカウント キーを取得することを意味します。		 いいえ true
secretName アカウント キーを格納するシークレット名を指定します。 いいえ
secretNamespace アカウント キーを格納するシークレットの名前空間を指定します。

注:
secretNamespace が指定されていない場合、シークレットはポッドと同じ名前空間内に作成されます。		 default、kube-systemなど いいえ PVC 名前空間 (csi.storage.k8s.io/pvc/namespace など)
useDataPlaneAPI ファイル共有の作成/削除/サイズ変更にデータ プレーン API を使用するかどうかを指定します。データ プレーン API には制限がほとんどないため、これによって SRP API のスロットリングの問題が解決する可能性がありますが、ストレージ アカウントにファイアウォールまたは VNet 設定がある場合は失敗します。 true または false いいえ false
--- 次のパラメーターは NFS プロトコル専用です --- ---
mountPermissions マウントされたフォルダーのアクセス許可。 既定では、 0777です。 0 に設定されている場合、ドライバーでは、マウント後に chmod を実行しません。 0777 いいえ
rootSquashType 共有でのルート スカッシュの動作を指定します。 既定値は NoRootSquash です AllSquash、NoRootSquash、RootSquash いいえ
--- 次のパラメーターは VNet 設定専用です。 たとえば、NFS、プライベート エンドポイント --- ---
fsGroupChangePolicy ドライバーがボリュームの所有権を変更する方法を示します。 ポッド securityContext.fsGroupChangePolicy は無視されます。 OnRootMismatch (既定値)、Always、None いいえ OnRootMismatch
subnetName サブネット名 エージェント ノードの既存のサブネット名。 いいえ 空の場合、ドライバーには Azure クラウド構成ファイル内の subnetName 値が使われます。
vnetName 仮想ネットワーク名 既存の仮想ネットワーク名。 いいえ 空の場合、ドライバーには Azure クラウド構成ファイル内の vnetName 値が使われます。
vnetResourceGroup 仮想ネットワークが定義されている VNet リソース グループを指定します。 既存のリソース グループ名。 いいえ 空の場合、ドライバーには Azure クラウド構成ファイル内の vnetResourceGroup 値が使われます。

ストレージ クラスの作成

ストレージ クラスは、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)

Note

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

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 を定義するために使用できるパラメータが含まれています。

名前 意味 使用できる値 Mandatory 既定値
volumeAttributes.resourceGroup Azure リソース グループ名を指定します。 myResourceGroup いいえ 空の場合、ドライバーでは、現在のクラスターと同じリソース グループ名が使われます。
volumeAttributes.storageAccount 既存の Azure ストレージ アカウント名を指定します。 storageAccountName はい
volumeAttributes.shareName Azure ファイル共有名を指定します。 fileShareName はい
volumeAttributes.folderName Azure ファイル共有内のフォルダー名を指定します。 folderName いいえ フォルダー名がファイル共有に存在しない場合、マウントは失敗します。
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 ドライバーがボリュームの所有権を変更する方法を示します。 ポッド securityContext.fsGroupChangePolicy は無視されます。 OnRootMismatch (既定値)、Always、None いいえ OnRootMismatch
volumeAttributes.mountPermissions マウントされたフォルダーのアクセス許可を指定します。 既定値は 0777 です いいえ

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:
      resourceGroup: resourceGroupName  # optional, only set this when storage account is not in the same resource group as node
      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

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

Note

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

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

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

    kubectl apply -f azure-files-pod.yaml

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

    kubectl describe pod mypod

次のステップ

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

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