この記事では、Azure ディスク ボリュームのマウントが失敗する原因となるエラーの解決策について説明します。
症状
デプロイや StatefulSet などの Kubernetes リソースを Azure Kubernetes Service (AKS) 環境にデプロイしようとしています。 デプロイにより、Azure ディスクを参照する PersistentVolumeClaim (PVC) をマウントするポッドが作成されます。
ただし、ポッドは ContainerCreating 状態のままです。
kubectl describe pods コマンドを実行すると、マウント操作が失敗する原因となる次のいずれかのエラーが表示されることがあります。
- ディスクは VM と同じゾーンにないため、VM に接続できません
- オブジェクト ID '<object-ID>' を持つクライアント '<client-ID>' には、スコープ '<disk name>' に対してアクションを実行する権限がありません。またはスコープが無効です
- ボリュームはポッドで既に使用されています
- StorageAccountType UltraSSD_LRSは、additionalCapabilities.ultraSSDEnabled が設定されている場合にのみ使用できます
- Vol に対して ApplyFSGroup が失敗しました
- ノードが最大ボリューム数を超えている
エラーの詳細、考えられる原因、解決策については、次のセクションを参照してください。
ディスクは VM と同じゾーンにないため、VM に接続できません
このエラーの詳細は次のとおりです。
AttachVolume.Attach failed for volume "<disk/PV name>":
rpc error:
code = Unknown
desc = Attach volume "/subscriptions/<subscription-ID>/resourceGroups/<disk-resource-group>/providers/Microsoft.Compute/disks/<disk/PV name>" to instance "<AKS node name>" failed with Retriable: false, RetryAfter: 0s, HTTPStatusCode: 400,
RawError:
{
"error":
{
"code": "BadRequest",
"message": "Disk /subscriptions/<subscription-ID>/resourceGroups/<disk-resource-group>/providers/Microsoft.Compute/disks/<disk/PV name > cannot be attached to the VM because it is not in the same zone as the VM. VM zone: 'X'. Disk zone: 'Y'. "
}
}
原因: ディスクと、ポッドをホストするノードが異なるゾーンにある
AKS では、Azure ディスクの既定のストレージ クラスとその他の組み込みストレージ クラスでは 、ローカル冗長ストレージ (LRS) が使用されます。 これらのディスクは可用性ゾーンにデプロイされます。 AKS のノード プールを可用性ゾーンと共に使用し、ポッドがディスクとは異なる別の可用性ゾーンにあるノードでスケジュールされている場合、このエラーが発生する可能性があります。
このエラーを解決するには、次のいずれかの解決策を使用します。
解決策 1: ディスクと、ポッドをホストするノードが同じゾーンにあることを確認する
ポッドをホストするディスクとノードが同じ可用性ゾーンにあることを確認するには、 ノード アフィニティを使用します。
例として、次のスクリプトを参照してください。
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: topology.disk.csi.azure.com/zone
operator: In
values:
- <region>-Y
<region> は AKS クラスターのリージョンです。
Y は、ディスクの可用性ゾーンを表します (例: westeurope-3)。
解決策 2: ゾーン冗長ストレージ (ZRS) ディスクを使う
ZRS ディスク ボリュームは、すべてのゾーンと非ゾーン エージェント ノード上でスケジュールできます。 詳細については、「Azure ディスク可用性ゾーンのサポート」を参照してください。
ZRS ディスクを使用するには、 Premium_ZRS または StandardSSD_ZRSを使用してストレージ クラスを作成し、ストレージを参照する PersistentVolumeClaim (PVC) をデプロイします。
パラメーターの詳細については、「 Driver パラメーター」を参照してください。
解決策 3: Azure Files を使用する
Azure Files は、ネットワーク全体で NFS または SMB を使用してマウントされます。 可用性ゾーンには関連付けされていません。
詳細については、次の記事をご覧ください。
オブジェクト ID '<object-ID>' のクライアント '<client-ID>' には、スコープ '<disk name>' に対してアクションを実行する権限がありません。またはスコープが無効です
このエラーの詳細は次のとおりです。
AttachVolume.Attach failed for volume "pv-azuredisk":
rpc error: code = NotFound
desc = Volume not found, failed with error: Retriable: false, RetryAfter: 0s, HTTPStatusCode: 403,
RawError:
{
"error":
{"code":"AuthorizationFailed",
"message":"The client '<client-ID>' with object id '<object-ID>' does not have authorization to perform action 'Microsoft.Compute/disks/read' over scope '/subscriptions/<subscription-ID>/resourceGroups/<disk-resource-group>/providers/Microsoft.Compute/disks/<disk name>' or the scope is invalid. If access was recently granted, please refresh your credentials."
}
}
原因: ディスクに対して必要な認可が AKS ID にありません
Azure ディスクに対して必要な認可が AKS クラスターの ID にありません。 この問題は、ディスクが AKS クラスターのインフラストラクチャ リソース グループ以外のリソース グループに作成されている場合に発生します。
解決策: 必要な認可を含むロールの割り当てを作成する
エラーごとに必要な承認を含むロールの割り当てを作成します。 共同作成者ロールを使うことをお勧めします。 別の組み込みロールを使う場合は、「Azure 組み込みロール」を参照してください。
共同作成者ロールを割り当てるには、次のいずれかの方法を使います。
az role assignment create コマンドを使用する
次に例を示します。
az role assignment create --assignee <AKS-identity-ID> --role "Contributor" --scope /subscriptions/<subscription-ID>/resourceGroups/<disk-resource-group>/providers/Microsoft.Compute/disks/<disk name>Azure portal を使用する
「Azure portal を使用して Azure ロールを割り当てる」で紹介されている詳細な手順を参照して、共同作成者ロールを割り当ててください。 マネージド ID に共同作成者ロールを割り当てる場合は、コントロール プレーン ID を使って Azure ディスクを管理します。
ボリュームはポッドで既に使用されています
このエラーの詳細は次のとおりです。
ボリューム "<PV/disk-name>" のマルチアタッチエラー: ボリュームはポッド <pod-name> によって既に使用されています。
原因: 異なるノード上でホストされている複数のポッドにディスクがマウントされている
Azure ディスクは ReadWriteOnce としてのみマウントできます。 これにより、AKS 内の 1 つのノードで使用できるようになります。 つまり、1 つのノードにのみアタッチでき、そのノードによってホストされているポッドにのみマウントできます。 同じディスクを別のノードのポッドにマウントすると、ディスクが既にノードに接続されているため、このエラーが発生します。
解決策: 異なるノードでホストされている複数のポッドによってディスクがマウントされていないことを確認する
このエラーを解決するには、「Multi-Attach エラー」を参照してください。
複数のノードにまたがる PersistentVolume を共有するには、Azure Files を使ってください。
StorageAccountType UltraSSD_LRSは、additionalCapabilities.ultraSSDEnabled が設定されている場合にのみ使用できます
このエラーの詳細は次のとおりです。
AttachVolume.Attach failed for volume "<Disk/PV name>" :
rpc error:
code = Unknown
desc = Attach volume "/subscriptions/<subscription-ID>/resourceGroups/<disk-resource-group>/providers/Microsoft.Compute/disks/<disk/PV name>" to instance "<AKS node name>" failed with Retriable: false, RetryAfter: 0s, HTTPStatusCode: 400, RawError:
{
"error":
{"code": "InvalidParameter",
"message": "StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.",
"target": "managedDisk.storageAccountType"
}
}
原因: Ultra Disks が無効なノード プールに Ultra Disk がアタッチされている
このエラーは、Ultra ディスクを無効にして、 Ultra ディスク をノード プールに接続しようとしていることを示します。 既定で、AKS ノード プール上の Ultra Disk は無効です。
解決策: Ultra Disks を使用できるノード プールを作成する
AKS で Ultra ディスクを使用するには、 --enable-ultra-ssd フラグを使用して Ultra ディスクがサポートされているノード プールを作成します。 詳細については、「Azure Kubernetes Service での Azure Ultra Disks の使用」を参照してください。
Vol に対して ApplyFSGroup が失敗しました
このエラーの詳細は次のとおりです。
ボリューム '<PV/disk-name>': applyFSGroup failed for vol /subscriptions/<subscriptionID>/resourceGroups/<infra/disk-resource-group>/providers/Microsoft.Compute/disks/<PV/disk-name>: [..]: 入力/出力エラー
原因: 大きなボリュームの所有権とアクセス許可の変更には時間がかかる
ボリュームに既に多数のファイルが存在し、fsGroupを使用するsecurityContextが存在する場合、このエラーが発生する可能性があります。 1 つのボリュームに多数のファイルとディレクトリがある場合、グループ ID を変更すると時間が過度に消費されます。 さらに、Kubernetes 公式ドキュメントでは、 ポッドのボリュームアクセス許可と所有権変更ポリシーの構成に関 する次の状況について説明しています。
「Kubernetes の既定では、ボリュームがマウントされるときに、各ボリュームのコンテンツの所有権とアクセス許可は、ポッドの fsGroup に指定された securityContext に一致するように再帰的に変更されます。 大きなボリュームの場合、所有権とアクセス許可の確認と変更に長い時間がかかり、ポッドの起動が遅くなることがあります。
fsGroupChangePolicy 内の securityContext フィールドを使って、Kubernetes がボリュームの所有権とアクセス許可を確認および管理する方法を制御することができます。」
解決方法: fsGroupChangePolicy フィールドを OnRootMismatch に設定する
このエラーを解決するには、デプロイ、StatefulSet、またはポッドのsecurityContextでfsGroupChangePolicy: "OnRootMismatch"を設定することをお勧めします。
OnRootMismatch: ルート ディレクトリのアクセス許可と所有権が、ボリュームの予想されるアクセス許可と一致しない場合にのみ、アクセス許可と所有権を変更します。 この設定は、ボリュームの所有権とアクセス許可の変更にかかる時間を短縮するのに役立ちます。
詳細については、「Configure volume permission and ownership change policy for Pods」(ポッドのボリュームのアクセス許可と所有権の変更ポリシーを構成する) を参照してください。
ノードが最大ボリューム数を超えている
このエラーの詳細は次のとおりです。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 25s default-scheduler 0/8 nodes are available: 8 node(s) exceed max volume count. preemption: 0/8 nodes are available: 8 No preemption victims found for incoming pod..
原因: ディスクの上限に達しました
ノードが最大ディスク容量に達しました。 AKS では、ノードあたりのディスク数は、ノード プール用に構成されている VM サイズによって異なります。
解決策
この問題を解決するには、次のいずれかの方法を使用します。
- より多くのディスク制限をサポートする VM サイズの新しいノード プールを追加します。
- ノード プールをスケーリングします。
- ノードから既存のディスクを削除します。
さらに、ノードあたりのディスク数が Kubernetes の既定の制限を超えていないことを確認します。
詳細情報
Azure Disk の既知の問題の詳細については、「 Azure ディスク プラグインの既知の問題を参照してください。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。