まとめ
この記事では、Microsoft Azure Kubernetes Service (AKS) クラスターを作成、デプロイ、または更新しようとしたときに発生する可能性がある ZonalAllocationFailed、 AllocationFailed、または OverconstrainedAllocationRequest エラーを特定して解決する方法について説明します。
[前提条件]
Azure CLI (省略可能)、バージョン 2.0.59、またはそれ以降のバージョン。 Azure CLI が既にインストールされている場合は、
az --versionを使用してバージョン番号を確認できます。Azure PowerShell (省略可能)。
症状
クラスターを作成、アップグレード、またはスケールアップしようとすると、次のいずれかのエラー メッセージが表示されます。
コード: ZonalAllocationFailed
メッセージ: Allocation failed. We do not have sufficient capacity for the requested VM size in this zone. Read more about improving likelihood of allocation success at https://aka.ms/allocation-guidance. Please note that allocation failures can also arise if a proximity placement group is associated with this VMSS. See https://learn.microsoft.com/troubleshoot/azure/azure-kubernetes/error-code-zonalallocationfailed-allocationfailed for more details. This is not AKS controlled behavior, please ask help to VMSS team for allocation failure. If the error is due to capacity constrain, consider upgrade with maxUnavailable instead of maxSurge, details: aka.ms/aks/maxUnavailable.
コード: AllocationFailed
メッセージ: The VM allocation failed due to an internal error. Please retry later or try deploying to a different location. Please note that allocation failures can also arise if a proximity placement group is associated with this VMSS. See https://learn.microsoft.com/troubleshoot/azure/azure-kubernetes/error-code-zonalallocationfailed-allocationfailed for more details. This is not AKS controlled behavior, please ask help to VMSS team for allocation failure.
コード: OverconstrainedAllocationRequest
メッセージ: Create or update VMSS failed. Allocation failed. VM(s) with the following constraints cannot be allocated, because the condition is too restrictive. Please remove some constraints and try again. Constraints applied are: - Differencing (Ephemeral) Disks - Networking Constraints (such as Accelerated Networking or IPv6) - VM Size
原因 1: SKU のゾーン可用性が制限されている
特定の SKU の可用性が制限されているゾーンにクラスターをデプロイ、アップグレード、またはスケールアップしようとしています。
解決策 1: 別の SKU、ゾーン、またはリージョンを使用する
次の 1 つ以上の方法を試してください。
- 別の SKU を使用して、同じリージョンにクラスターを再デプロイします。
- そのリージョンの別のゾーンにクラスターを再デプロイします。
- クラスターを別のリージョンに再デプロイします。
- 別のゾーンに新しいノード プールを作成するか、別の SKU を使用します。
このエラーを修正する方法の詳細については、「 使用できない SKU のエラーを解決する」を参照してください。
解決策 2: ノード自動プロビジョニングを使用して動的にスケーリングする
Node Auto Provisioning を 使用すると、ワークロードのニーズに基づいて VM SKU を自動的にプロビジョニングできます。 容量の制約のために SKU を使用できない場合、Node Auto Provisioning (NAP) は、 NodePool や AKSNodeClassなど、顧客のリソース定義 (CRD) で指定された仕様に基づいて別の SKU の種類を選択します。 これは、特定の SKU 容量が制限されるシナリオのスケーリングに役立ちます。 NAP クラスターの構成の詳細については、 Azure Kubernetes Service (AKS) でのノード自動プロビジョニング (NAP) 用のノード プールの構成と、Azure Kubernetes Service (AKS) での ノード自動プロビジョニング (NAP) 用の AKSNodeClass リソースの構成に関するページを参照してください。
解決策 3: MaxUnavailable を使用してインプレースアップグレードを行う
アップグレード中にサージ ノードが必要ない場合は、既存の容量でアップグレードする方法については、「 使用できないノードをカスタマイズ する」を参照してください。
MaxUnavailableをゼロ (0) より大きい値に設定し、MaxSurgeゼロ (0) に設定します。 その後、既存のノードは一度に1つずつ隔離されて処理が終了し、ポッドは残りのノードに退避されます。 バッファー ノードは作成されません。
解決策 4: 新しいクラスター作成にポータルでデプロイ レコメンダーを使用する
Azure portal での AKS クラスターの作成中に、選択したノード プール SKU が選択したリージョンとゾーンで使用できない場合、デプロイ レコメンダーは可用性を備える代替 SKU、ゾーン、リージョンの組み合わせを推奨します。
解決策 5: クラスター オートスケーラーで優先度エキスパンダーを使用する
クラスター オートスケーラー 優先度エキスパンダー を使用すると、順番にスケーリングを試みるノード プールの順序付きリストを定義できます。 たとえば、最初にスポット プール (コストの最適化)、オンデマンド プール (可用性フォールバック) などです。 条件付きアクセスは、最も優先度の高いプールを最初に実装しようとします。 スケーリングが失敗した場合 (割り当てエラーなど)、次のプールが試行されます。
制限事項
条件付きアクセスでは、新しいノード プールは作成されません。 既存のプールでのみ機能します。 動的 SKU プロビジョニングが必要な場合は、SKU の可用性に基づいてプールを作成できる NAP を使用します。
優先度エキスパンダーは、SKU レベルではなくノード プール レベルで動作します。 使用する SKU ファミリごとにプールを事前に作成する必要があります。
原因 2: 仮想マシンが対応するには制約が多すぎます
OverconstrainedAllocationRequestエラー コードを受け取った場合、Azure Compute プラットフォームは、必要な制約に対応するために新しい仮想マシン (VM) を割り当てることはできません。 これらの制約には通常 (常にではありませんが) 次の項目が含まれます。
- VM サイズ
- VM SKU (仮想マシン製品番号)
- 高速ネットワーク
- 可用性ゾーン
- 一時的なディスク
- 近接配置グループ (PPG)
解決策: 近接通信配置グループをノード プールに関連付けない
OverconstrainedAllocationRequestエラー コードが表示された場合は、近接通信配置グループに関連付けられていない新しいノード プールを作成してみてください。
原因 3: 専用ホストまたは障害ドメインが不足している
容量が制限されているか、障害ドメインの制約を満たしていない専用ホスト グループにノード プールをデプロイしようとしています。
解決策: AKS ノード/VMSS 用の専用ホストが十分にあることを確認する
AKS での ADH 容量の計画に従って、AKS VMSS で必要な数の障害ドメインにまたがるように、十分な専用ホストを計画する必要があります。 たとえば、AKS VMSS が FaultDomainCount=2 で作成されている場合は、異なる障害ドメイン (FaultDomain 0 と FaultDomain 1) に少なくとも 2 つの専用ホストが必要です。
詳細情報
ユーザーの容量の確保は Microsoft にとって最優先事項であり、この目標を達成するために 24 時間体制で取り組んでいます。 Azure サービスの人気が高まっている中で、インフラストラクチャをさらに迅速にスケールアップする必要性が強調されています。 そのことを念頭に置いて、お客様の強い需要に対応するために、拡張を迅速化し、リソースのデプロイ プロセスを改善しています。 また、毎月大量のコンピューティング インフラストラクチャを追加しています。
リソース使用率の高い状況で負荷分散を行う方法と、必要なリソースのタイムリーなデプロイをトリガーする方法を改善するためのいくつかの方法を特定しました。 さらに、生産能力を大幅に増やし、すべてのリージョンでの強い需要に対応する計画を続けています。 回復性の高いクラウド サプライ チェーンの提供に向けて行っている機能強化の詳細については、「回復性のあるクラウド サプライ チェーン による信頼性の向上」を参照してください。