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 ストレージ クラスに関するページを参照してください。
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
Note
ストレージ クラスに
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 コンテナーの場合、 'D:' などの Windows パス規則を使用して mountPath
を指定します。
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
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 ストレージ アカウントとファイル共有を作成する必要があります。
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: 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
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
ファイル共有をインライン ボリュームとしてマウントする
Note
パフォーマンスの問題を回避するために、多数のポッドが同じファイル共有にアクセスしている場合は、インライン ボリュームではなく永続ボリュームを使用することをお勧めします。 インライン ボリュームがアクセスできるのはポッドと同じ名前空間内のシークレットだけです。 別のシークレットの名前空間を指定するには、永続ボリュームを使用します。
Azure Files ファイル共有をポッドにマウントするには、コンテナーの指定でボリュームを構成します。
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
kubectl apply
コマンドを使用してポッドを作成します。kubectl apply -f azure-files-pod.yaml
これで、/mnt/azure にマウントされた Azure Files ファイル共有を使ってポッドが実行するようになりました。
kubectl describe
コマンドを使用して、共有が正常にマウントされていることを確認できます。kubectl describe pod mypod
次のステップ
Azure File CSI ドライバー パラメーターについては、「CSI ドライバー パラメーター」を参照してください。
関連するベスト プラクティスについては、AKS のストレージとバックアップに関するベスト プラクティスに関する記事を参照してください。
Azure Kubernetes Service