次の方法で共有

Azure Kubernetes Service (AKS) のクォータ、仮想マシンのサイズの制限、およびリージョンの可用性

Azure サービスでは、特定の仮想マシン (VM) SKU の使用制限など、リソースと機能の既定の制限とクォータが設定されます。

この記事では、Azure Kubernetes Service (AKS) リソースに対する既定のリソースの制限と、Azure リージョンでの AKS の可用性について詳しく説明します。

サービスのクォータと制限

リソース 制限
サブスクリプションあたりのグローバルなクラスターの最大数 5,000
Virtual Machine Scale Sets と Standard Load Balancer SKU を使用したクラスターあたりの最大ノード数 5000 (すべてのノード プール対象)
注: クラスターあたり最大 5000 ノードまでスケールアップできない場合は、大規模なクラスターのベスト プラクティスを参照してください。
ノード プールあたりの最大ノード数 (Virtual Machine Scale Sets ノード プール) 1000
クラスターあたりの最大ノード プール数 100
ノードあたりの最大ポッド数: Kubenet ネットワーク プラグイン 最大値: 250
Azure CLI の既定値: 110
Azure Resource Manager テンプレートの既定値: 110
Azure portal デプロイの既定値: 30
ノードあたりの最大ポッド数: Azure Container Networking Interface (Azure CNI)1 最大値: 250
Windows Server コンテナーに推奨される最大値: 110
既定値: 30
Open Service Mesh (OSM) AKS アドオン Kubernetes クラスターのバージョン: AKS でサポートされているバージョン
クラスターあたりの OSM コントローラー数: 1
OSM コントローラーあたりのポッド数: 1600
OSM によって管理される Kubernetes サービス アカウント数: 160
Standard Load Balancer SKU を使用した場合のクラスターごとの最大 Kubernetes 負荷分散サービス数 300
仮想マシン可用性セットと Basic Load Balancer SKU を使用したクラスターあたりの最大ノード 100

1 つの Windows Server コンテナーでは、Azure CNI ネットワーク プラグインを使用する必要があります。 Kubenet は Windows Server コンテナーではサポートされていません。

Kubernetes コントロール プレーンのサービス レベル 制限
スタンダードティア 負荷に基づいて Kubernetes API サーバーを自動的にスケーリングします。 より大きなコントロール プレーン コンポーネントの制限と API サーバー/etcd インスタンス。
Free レベル インフライト要求の制限がある限られたリソース。 クラスターあたり 10 個のノードという推奨ノード制限。 実験、学習、簡単なテストに最適です。 運用環境や重要なワークロードにはお勧めしません。

AKS マネージド クラスターのクォータ制限

2025 年 9 月から、Azure Kubernetes Service は、現在および新規のすべての AKS 顧客のクォータを有効にする変更のロールアウトを開始します。 このロールアウトは、2025 年 9 月 1 日から 30 日の間に実施される予定です。

AKS クォータは、Azure サブスクリプションがリージョンごとに作成できるマネージド クラスター (AKS クラスター) の最大数の制限を表します。 マネージド クラスター クォータが解放されると、AKS クラスターを作成するには、マネージド クラスターのクォータとノード (VM SKU) のクォータの両方が必要になります。

既存の AKS 顧客サブスクリプションには、 利用可能なリージョンの容量に応じて、現在の使用量以上の既定の制限が適用されます。 AKS を初めて使用する既存のサブスクリプションと新しいサブスクリプション には、既定の制限が適用されます。

顧客は、Azure portal の [クォータ] ページまたはクォータ REST API を使用して、クォータの制限と使用状況を表示し、追加のクォータを要求できます。 ロールアウト完了の前には、クォータの制限と使用状況がポータルの [クォータ] ブレードに表示され、顧客はクォータを要求できますが、ロールアウトが完了するまで制限は適用されません。

Azure portal の [クォータ] ページのスクリーンショット。

マネージド クラスター クォータがロールアウトされると、新しいクラスターを作成しようとしてクォータが不足している場合、次のエラーが表示されます。

ManagedClusterCountExceedsQuotaLimit: Operation results in exceeding quota limits for managed clusters. Maximum allowed: %d, Current usage: %d, Additional requested: %d. Consider deleting unused clusters or requesting a quota increase. To request a quota increase, follow the instructions here: https://learn.microsoft.com/azure/quotas/quickstart-increase-quota-portal.

これを解決するために、お客様は Azure portal の [クォータ] ページ または クォータ REST API を使用して、追加のクォータを要求できます。

AKS マネージド クラスターのクォータ制限

サブスクリプションの種類 新しいサブスクリプションのリージョンごとのサブスクリプションあたりの AKS クラスターの既定の数1 Azure portal クォータ ページを使用したセルフサービスにより、リージョンごとのサブスクリプションあたりに許可される AKS クラスターの最大数は 2 です。
Enterprise Agreement サブスクリプション 100 1,000
CSP、従量課金制、スポンサー付き、MSDN、MPN、Azure Pass、Azure In Open、Azure Pass サブスクリプション 10 100
無料試用版と Azure for Students サブスクリプション 3 3

1 新しいサブスクリプションのリージョンごとのサブスクリプションあたりの AKS クラスターの既定の数は、容量の制約があるリージョンによって異なる場合があります。
2 クォータ制限の引き上げを要求するには、 Azure portal クォータ要求プロセスを使用します。 最大セルフサービス量を超えるクォータの引き上げ要求には、サポート チケットが必要です。 無料試用版と Azure for Students サブスクリプションは、制限またはクォータの引き上げの対象ではありません。 無料試用版または Azure for Students サブスクリプションをお持ちの場合は、従量課金制サブスクリプションにアップグレードして、より高いクォータ制限を取得できます。

AKS リソース プロバイダー API のスロットリングの制限

AKS では、トークン バケット 調整アルゴリズムを使用して、特定の AKS リソース プロバイダー API を制限します。 スロットリング制限により、サービスのパフォーマンスを保証し、すべての顧客に対するサービス利用の公平性が促進されます。

バケットには固定サイズ (バースト レートとも呼ばれます) があり、一定のレート (持続レートとも呼ばれます) で時間の経過と同時に補充されます。 各スロットル制限は、その地域の指定されたリソースに対し、地域レベルで有効です。 たとえば、次の表では、サブスクリプションは ResourceGroup ごとに一度に最大 60 回 (バースト レート) ListManagedClusters を呼び出すことができますが、その後も 1 秒ごとに 1 回の呼び出しを続けることができます (継続レート)。

API 要求 バケット サイズ リフィル レート Scope
LISTマネージドクラスター 500 件の要求 1 要求/ 1 秒 サブスクリプション
LISTマネージドクラスター 60 件の要求 1 リクエスト/1 秒 リソースグループ （ResourceGroup）
PUT AgentPool 20 件の要求 1 要求/1 分 AgentPool
PUT マネージドクラスター 20 件の要求 1 要求/1 分 マネージドクラスタ
GET ManagedCluster 60 件の要求 1 リクエスト/1 秒 マネージド クラスター
GET 操作の状態 200 件の要求 2 要求/ 1 秒 サブスクリプション
その他すべての API 60 件の要求 1 リクエスト/1 秒 サブスクリプション

注

ManagedClusters バケットと AgentPools バケットは、同じ AKS クラスターに対して個別にカウントされます。

要求が制限されると、要求は HTTP 応答コード 429 (リクエストが多すぎる) を返し、エラーコードは応答に Throttled と表示されます。 調整された各要求には、HTTP 応答ヘッダー内にあるRetry-Afterに、再試行するまでの待機時間（秒単位）が含まれています。 バースト API 呼び出しパターンを使用するクライアントは、Retry-After を適切に処理できるようにする必要があります。 Retry-After の詳細については、 次の記事を参照してください。 具体的には、AKS は delay-seconds を使用して再試行を指定します。

プロビジョニングされたインフラストラクチャ

その他のすべてのネットワーク、コンピューティング、およびストレージの制限が、プロビジョニングされるインフラストラクチャに適用されます。 関連する制限については、Azure サブスクリプションとサービスの制限に関するページを参照してください。

重要

AKS クラスターをアップグレードすると、追加のリソースが一時的に消費されます。 これらのリソースには、仮想ネットワークのサブネット内で利用可能な IP アドレスや、仮想マシンの vCPU クォータが含まれます。

Windows Server コンテナーの場合、アップグレードの操作を実行すると最新のノード更新プログラムを適用できます。 これらの一時的なリソースを処理するために使用可能な IP アドレス空間または vCPU クォータがない場合、クラスターのアップグレード プロセスは失敗します。 Windows Server ノードのアップグレード プロセスの詳細については、AKS でのノード プールのアップグレードに関するページを参照してください。

サポートされる VM のサイズ

AKS でサポートされている VM サイズの一覧は、Azure で新しい VM SKU がリリースされることに伴い進化しています。 AKS のリリース ノートに従って、サポートされている新しい SKU を常に把握します。

制限されている VM サイズ

AKS クラスター内の各ノードには、vCPU やメモリなどの一定量のコンピューティング リソースが含まれています。 Kubernetes を正しく実行するために必要なコンピューティング リソースにより、AKS では特定の VM SKU サイズが既定で制限されます。 これらの制限は、ポッドをスケジュールし、これらのノードで正しく機能できるようにするためです。

ユーザー ノード プール

ユーザー ノード プールの場合、2 つ未満の vCPU と 2 GB の RAM (メモリ) を持つ VM サイズが使用されない場合があります。

システム ノード プール

システム ノード プールの場合、2 つ未満の vCPU と 4 GB の RAM (メモリ) を持つ VM サイズが使用されない場合があります。 必要な kube-system ポッドとアプリケーションを確実にスケジュールできるようにするには、B シリーズ VM と Av1 シリーズ VM を使用しないことをお勧めします。

VM の種類とそのコンピューティング リソースの詳細については、Azure での仮想マシンのサイズに関するページを参照してください。

サポートされているコンテナー イメージのサイズ

AKS では、コンテナー イメージのサイズに制限は設定されません。 ただし、コンテナー イメージが大きいほどメモリ需要が高くなることを理解しておくことが重要です。 この要求は、リソースの制限またはワーカー ノードの使用可能なメモリ全体を超える可能性があります。 既定では、AKS クラスターの VM サイズ Standard_DS2_v2 のメモリは 7 GiB に設定されます。

コンテナー イメージが大きい (1 TiB 以上) 場合、ディスク領域がないため、kubelet がコンテナー レジストリからノードにプルできない可能性があります。

利用可能なリージョン

クラスターをデプロイおよび実行できる場所の最新のリストについては、AKS リージョンの可用性に関するページを参照してください。

スマート VM の既定値

2025 年 5 月の時点で、デプロイ中にパラメーターが指定されていない場合、AKS は使用可能な容量とクォータに基づいて最適な既定の VM SKU を自動的に選択します。 この既定値により、デプロイが可能な限り最適な SKU と一致し、パフォーマンスと信頼性が向上し、リソース使用率が最適化されます。 以前は、既定の AKS VM SKU はStandard_DS2_V2されていましたが、すべての新しい VM 作成操作に影響する SKU の可用性に基づいて、既定のプロビジョニングに動的な結果が生じていました。

Azure portal のクラスター構成プリセット

Azure portal を使用してクラスターを作成するときは、シナリオに基づいて簡単にカスタマイズするために、プリセットの構成を選択できます。 プリセットの値はいつでも変更できます。

プリセット 説明
運用基準 AKS で推奨されるベスト プラクティスを使用して運用トラフィックを提供するほとんどのアプリケーションに最適です。
Dev/Test 新しいワークロードの開発や既存のワークロードのテストに最適です。
運用エコノミー ワークロードが中断を許容できる場合には、コストを意識しながら運用トラフィックを処理するのに最適です。
運用エンタープライズ アクセス許可が厳密でセキュリティが強化された運用トラフィックを提供するのに最適です。
運用基準 Dev/Test 運用エコノミー 運用エンタープライズ
システム ノード プールのノード サイズ Standard_D8ds_v5 Standard_D4ds_v5 Standard_D8ds_v5 Standard_D16ds_v5
システム ノード プールの自動スケーリング範囲 2 から 5 ノード 2 から 5 ノード 2 から 5 ノード 2 から 5 ノード
ユーザーノードプール内のノードサイズ Standard_D8ds_v5 - Standard_D8as_v4 Standard_D8ds_v5
ユーザー ノード プールの自動スケーリング範囲 2 から 100 ノード - 0 から 25 ノード 2 から 100 ノード
プライベート クラスター - - -
可用性ゾーン - -
Azure Policy - -
Azure Monitor - -
シークレット ストア CSI ドライバー - -
ネットワーク構成 Azure CNI オーバーレイ Azure CNI オーバーレイ Azure CNI オーバーレイ Azure CNI オーバーレイ
ネットワーク ポリシー なし なし なし なし
認証と承認 Kubernetes ロールベースのアクセス制御 (RBAC) を使用するローカル アカウント Kubernetes RBAC を使用したローカル アカウント Azure ロールベースのアクセス制御 (Azure RBAC) を使用した Microsoft Entra ID 認証 Azure RBAC を使用した Microsoft Entra ID 認証

次のステップ

特定のデフォルトの制限とクォータを増やすことができます。 リソースで増加がサポートされている場合は、Azure サポート リクエストを使用して増加を要求してください ( [問題の種類] で [クォータ] を選択してください)。