Azure Arc で有効になっている AKS のリソース制限、VM サイズ、リージョン

適用対象: AKS on Azure Stack HCI 22H2、AKS on Windows Server

この記事では、Azure Arc で有効になっているAzure Kubernetes Service (AKS) のテスト済み構成、リソース制限、VM サイズ、リージョンについて説明します。このテストでは、AKS on Azure Stack HCI の最新リリースを使用しました。

最大仕様

Arc デプロイで有効になっている AKS は、指定された最大値を含む次の構成で検証されています。 これらの最大値より大きくすると、予期しない動作やエラーが発生する可能性があります。そうする場合は、ご自身の責任で行ってください。 この記事は、一般的な構成ミスを回避する方法についてのガイダンスを示すもので、大規模な構成を作成するのに役立ちます。 疑問がある場合は、お住まいの地域の Microsoft オフィスに問い合わせてサポートを受けるか、Azure Stack HCI コミュニティで質問を投稿してください。

リソース 最大値
クラスターあたりの物理サーバー数 8
バーチャル マシンの合計数 200

推奨される制限は、次の表に基づいて、既定の仮想マシン (VM) サイズでテストされました。

システム ロール VM サイズ
AKS-Host Standard_A4_v2
[ターゲット クラスター コントロール プレーン] ノード [Default]
ターゲット クラスター HAProxy ロード バランサー (省略可能) Standard_A4_v2
ターゲット クラスター Linux ワーカー ノード Standard_K8S3_v1
ターゲット クラスターの Windows ワーカー ノード Standard_K8S3_v1

Azure Stack HCI クラスター内の各物理ノードのハードウェア構成は次のとおりです。

  • シャーシ: Dell PowerEdge R650 Server または同様。
  • RAM: RDIMM、3200 MT/秒、デュアル ランク、合計 256 GB。
  • CPU: 2 つ (2) Intel Xeon Silver 4316 2.3G、20C/40T、10.4 GT/s、30M キャッシュ、Turbo、HT (150 W) DDR4-2666。
  • ディスク: 8x HDD (2 TB 以上) と 2x 1.6 TB NVMe で、S2D ストレージ構成をサポートします。
  • ネットワーク: 4 個 (4) 100 Gbit NIC (Mellanox または Intel)。

Microsoft エンジニアリングでは、上記の構成を使用して Arc で有効になっている AKS をテストしました。 単一ノードの場合。 2 ノード、4 ノード、8 ノードの Windows フェールオーバー クラスター。 テスト済みの構成を超える必要がある場合は、「 Azure Stack HCI での AKS のスケーリング」を参照してください。

重要

AKS のデプロイをアップグレードすると、追加のリソースが一時的に使用されます。 各仮想マシンは、コントロール プレーン ノードから始まるローリング更新フローでアップグレードされます。 Kubernetes クラスター内の各ノードについて、新しいノード VM が作成されます。 古いノード VM は、ワークロードがデプロイされないように制限されています。 その後、制限付き VM は、システム内の他の VM にコンテナーを配布するために、すべてのコンテナーのドレインされます。 その後、ドレインされた VM がクラスターから削除され、シャットダウンされ、新しく更新された VM に置き換えられます。 このプロセスは、すべての VM が更新されるまで繰り返されます。

使用可能な VVM のサイズ

AKS on Azure Stack HCI では、コントロール プレーン ノード、Linux ワーカー ノード、および Windows ワーカー ノードの次の VM サイズを使用できます。 Standard_K8S2_v1Standard_K8S_v1などの VM サイズは、テストとリソース要件の低いデプロイでサポートされていますが、これらのサイズは注意して使用し、メモリ不足状態のために予期しないエラーが発生する可能性があるため、厳しいテストを適用してください。

[VM サイズ] CPU メモリ (GB) GPU の種類 GPU 数
Default 4 4
Standard_A2_v2 2 4
Standard_A4_v2 4 8
Standard_D2s_v3 2 8
Standard_D4s_v3 4 16
Standard_D8s_v3 8 32
Standard_D16s_v3 16 64
Standard_D32s_v3 32 128
Standard_DS2_v2 2 7
Standard_DS3_v2 2 14
Standard_DS4_v2 8 28
Standard_DS5_v2 16 56
Standard_DS13_v2 8 56
Standard_K8S_v1 4 2
Standard_K8S2_v1 2 2
Standard_K8S3_v1 4 6
Standard_NK6 6 12 Tesla T4 1
Standard_NK12 12 24 Tesla T4 2

Azure の登録でサポートされている Azure リージョン

Arc で有効になっている AKS は、次の Azure リージョンでサポートされています。

  • オーストラリア東部
  • 米国東部
  • 東南アジア
  • 西ヨーロッパ

AKS on Azure Stack HCI のスケーリング

Azure Stack HCI での AKS デプロイのスケーリングには、ワークロードを把握し、クラスターの使用率をターゲットにすることで、事前に計画する必要があります。 さらに、CPU コアの合計、メモリの合計、ストレージ、IP アドレスなど、基になるインフラストラクチャ内のハードウェア リソースを検討してください。

次の例では、基になるインフラストラクチャに AKS ベースのワークロードのみがデプロイされていることを前提としています。 スタンドアロンまたはクラスター化された仮想マシン、データベース サーバーなどの AKS 以外のワークロードをデプロイすると、AKS で使用できるリソースが減ります。これは考慮する必要があります。

開始する前に、最大スケールとサポートする必要があるターゲット クラスターの数を決定するために、次の点を考慮してください。

  • ターゲット クラスター内のポッドで使用できる IP アドレスの数。
  • ターゲット クラスター内の Kubernetes サービスで使用可能な IP アドレスの数。
  • ワークロードを実行するために必要なポッドの数。

Azure Kubernetes Service ホスト VM のサイズを確認するには、AKS ホスト VM のサイズを決定するため、ワーカー ノードとターゲット クラスターの数を把握する必要があります。 例:

  • 最終的にデプロイされたシステム内のターゲット クラスターの数。
  • すべてのターゲット クラスターにわたるコントロール プレーン、ロード バランサー、ワーカー ノードを含むノードの数。

注意

1 つの AKS ホストで管理できるのは、同じプラットフォーム上のターゲット クラスターのみです。

また、ターゲット クラスター コントロール プレーン ノードのサイズを決定するには、各ターゲット クラスターにデプロイする予定のポッド、コンテナー、ワーカー ノードの数を把握する必要があります。

AKS で現在変更できない既定の設定

既定の構成と設定は、現在、デプロイ中またはデプロイ後に顧客の制御に使用できません。 これらの設定では、特定のターゲット クラスターのスケールを制限できます。

  • ターゲット クラスター内の Kubernetes ポッドの IP アドレス数は、サブネット 10.244.0.0/16 に制限されます。 つまり、すべての Kubernetes 名前空間にわたってワーカー ノードあたり 255 個の IP アドレスをポッドに使用できます。 クラスター内の各ワーカー ノードに割り当てられたポッドの CIDR を確認するには、PowerShell で次のコマンドを使用します。
kubectl get nodes -o json | findstr 'hostname podCIDR'
                    "kubernetes.io/hostname": "moc-lip6cotjt0f",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.2.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-lmb6zqozk4m",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.4.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-wgwhhijxtfv",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.5.0/24",
                "podCIDRs": [

この例では、3 つの CIDR を持つ 3 つのノードを確認できます。それぞれが 254 ポッドをホストできます。 Kubernetes スケールドキュメントでは、パフォーマンス上の理由から、ノードあたり 110 ポッドを超えないようにすることをお勧めします。 「大規模なクラスターに関する考慮事項」を参照してください。

その他の考慮事項

  • 割り当てた VIP プールの外部にある Kubernetes サービスの IP アドレスの数は、アドレス プールから 10.96.0.0/16 取得されます。 システムは、Kubernetes API サーバーで使用可能な 255 個のアドレスのいずれかを使用します。
  • AKS ホスト VM のサイズは、 Set-AksHciConfig を初めて実行する場合にのみ、インストール時に設定できます。 これは後で変更することはできません。
  • ターゲット クラスターの作成時にのみ、ターゲット クラスター コントロール プレーンとロード バランサー VM のサイズを設定できます。

スケーリングの例

次のスケーリング例は、これらの一般的な前提条件/ユース ケースに基づいています。

  • Azure Stack HCI クラスター内の 1 つの物理ノードの損失を完全に許容できるようにする必要がある。
  • ターゲット クラスターを新しいバージョンにアップグレードすることをサポートする必要がある。
  • ターゲット クラスター コントロール プレーン ノードとロード バランサー ノードの高可用性を許可する必要があります。
  • これらのケースのために、Azure Stack HCI 容量全体の一部を予約する必要がある。

推奨事項

  • 最適なパフォーマンスを得るために、1 つの物理ノードのすべてのリソースを他の 7 つのノードに再配布できるように、クラスター容量の少なくとも 15% (100/8=12.5) を設定してください。 この構成により、アップグレードまたはその他の AKS の 2 日目の操作を実行するために利用できる予約が確保されます。

  • 最大ハードウェア サイズ 8 (8) ノード Azure Stack HCI クラスターの 200 VM 制限を超えて拡張する場合は、AKS ホスト VM のサイズを増やします。 サイズを 2 倍にすると、管理できる VM の数が約 2 倍になります。 8 ノードの Azure Stack HCI クラスターでは、「 サポートされているハードウェアの最大仕様」に記載されている Azure Stack HCI 推奨リソース制限に基づいて、8,192 (8x1024) VM にアクセスできます。 容量の約 30% を予約する必要があります。これにより、すべてのノードで 5,734 VM の理論上の制限が残されます。

    • Standard_D32s_v3、32 コアと 128 GB の AKS ホストでは、最大 1,600 ノードをサポートできます。

    注意

    この構成は広範囲にテストされていないため、慎重なアプローチと検証が必要です。

  • このような規模で、環境を少なくとも 8 つのターゲット クラスターに分割し、それぞれにワーカー ノードが 200 個ある場合があります。

  • 1 つのターゲット クラスターで 200 個のワーカー ノードを実行するには、既定のコントロール プレーンとロード バランサーのサイズを使用できます。 ノードあたりのポッド数に応じて、コントロール プレーンで少なくとも 1 つのサイズを上げ、 Standard_D8s_v3を使用できます。

  • 各ターゲット クラスターでホストされている Kubernetes サービスの数によっては、高パフォーマンスでサービスに到達し、それに応じてトラフィックがルーティングされるように、ターゲット クラスターの作成時にロード バランサー VM のサイズを増やす必要がある場合があります。

Arc によって有効になっている AKS のデプロイでは、Azure Stack HCI 配置ロジックを使用して、ターゲット クラスター内の各ノード プールのワーカー ノードが、使用可能な Azure Stack HCI ノードに分散されます。

重要

ノードの配置は、プラットフォームと AKS のアップグレード中は保持されず、時間の経過と同時に変化します。 障害が発生した物理ノードは、残りのクラスター ノード全体の仮想マシンの分散にも影響します。

注意

物理クラスターが既に 50% 満杯になっている場合は、同時に 4 つ以上のターゲット クラスターの作成を実行しないでください。一時的なリソースの競合が発生する可能性があります。 ターゲット クラスター ノード プールを多数スケールアップする場合、AKS では作成/スケーリング プロセスを並列実行するためのリソースの可用性が検証されないため、使用可能な物理リソースを考慮してください。 アップグレードとフェールオーバーのための十分な予備を必ず確保してください。 特に非常に大規模な環境では、これらの操作を並列で実行すると、リソースの枯渇が急速に発生する可能性があります。

不明な場合は、ローカルの Microsoft オフィスに問い合わせてサポートを受けるか、 Azure Stack HCI コミュニティ フォーラムに投稿してください。

次のステップ