次の方法で共有

Windows Server 上の AKS のリソース制限、VM サイズ、リージョン

適用対象: Windows Server 上の AKS

この記事では、Windows Server 上の Azure Kubernetes Service (AKS) のテスト済み構成、リソース制限、VM サイズ、リージョンについて説明します。 テストでは、Windows Server 上の AKS の最新リリースを使用します。

最大仕様

Windows Server 上の AKS の展開は、指定された最大値を含む次の構成で検証されました。 これらの最大値を超えると、予期しない動作やエラーが発生する可能性があります。 この記事では、一般的な構成ミスを回避する方法に関するガイダンスを提供し、より大きな構成を作成するのに役立ちます。 サポートが必要な場合は、ローカルの Microsoft オフィスに問い合わせるか 、コミュニティに質問を送信してください。

リソース 最大値
クラスターあたりの物理サーバー数 8
VM の合計数 200

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

システム役割 VM サイズ
AKS ホスト Standard_A4_v2
ターゲット クラスター コントロール プレーン ノード 既定値
ターゲット クラスター HAProxy ロード バランサー (省略可能) Standard_A4_v2
ターゲット クラスター Linux ワーカー ノード Standard_K8S3_v1
ターゲット クラスターの Windows ワーカー ノード Standard_K8S3_v1

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

  • シャーシ: 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 Cache、Turbo、HT (150 W) DDR4-2666。
  • ディスク: 8 倍の HDD (2 TB 以上) と 2 x 1.6 TB の NVMe で、S2D ストレージ構成をサポートします。
  • ネットワーク: 4 個 (4) 100 Gbit NIC (Mellanox または Intel)。

Microsoft エンジニアリングでは、単一ノード、2 ノード、4 ノード、および 8 ノードの Windows フェールオーバー クラスターに対して、この構成を使用して Windows Server 上の AKS をテストしました。 テスト済みの構成を超える要件がある場合は、「 AKS のスケーリング」を参照してください。

重要

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

使用可能な VVM のサイズ

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

VM サイズ CPU メモリ (GB) GPU のタイプ GPU 数
既定値 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 リージョン

Windows Server 上の AKS は、次の Azure リージョンでサポートされています。

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

AKS のスケーリング

AKS デプロイをスケーリングするには、計画が必要です。 ワークロードとターゲット クラスターの使用率を理解する必要があります。 また、CPU コアの合計、メモリの合計、ストレージ、IP アドレスなど、基になるインフラストラクチャ内のハードウェア リソースも考慮してください。

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

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

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

Azure Kubernetes Service ホスト VM のサイズを決定するには、ワーカー ノードとターゲット クラスターの数を把握する必要があります。 この情報によって、AKS ホスト VM のサイズが決まります。 次に例を示します。

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

注

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

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

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

デプロイ中またはデプロイ後に、一部の既定の構成と設定を変更することはできません。 これらの設定では、特定のターゲット クラスターのスケールを制限できます。

  • サブネット 10.244.0.0/16 では、ターゲット クラスター内の Kubernetes ポッドの IP アドレスの数が制限されます。 この制限は、各ワーカー ノードがすべての 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 ポッドを超えないようにすることをお勧めします。 大規模なクラスターの 管理に関するを参照してください。

その他の考慮事項:

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

スケーリングの例

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

  • Kubernetes クラスター内の 1 つの物理ノードの損失を許容する必要があります。
  • ターゲット クラスターを新しいバージョンにアップグレードすることをサポートする必要がある。
  • ターゲット クラスターのコントロール プレーン ノードとロード バランサー ノードの高可用性が必要です。
  • このような場合は、Windows Server の全体的な容量の一部を予約する必要があります。

推奨事項

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

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

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

    注

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

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

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

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

Windows Server での AKS のデプロイでは、配置ロジックを使用して、ターゲット クラスター内の各ノード プールのワーカー ノードが、使用可能なノードに分散されます。

重要

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

注

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

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

次のステップ

  • Last updated on