Azure Kubernetes Service (AKS)の大規模なワークロードのパフォーマンスとスケーリングに関するベスト プラクティス

注記

この記事では、大規模なワークロードに関する一般的なベスト プラクティスに焦点を当てます。 小規模から中規模のワークロードに関するベスト プラクティスは、Azure Kubernetes Service (AKS) の中小規模ワークロードのパフォーマンスとスケーリングのベスト プラクティスを参照してください。

ほとんどの運用環境の AKS ワークロードでは、 AKS Automatic から始めます。 AKS Automatic は、AKS で推奨される運用環境対応の既定値であり、スケーリング、セキュリティ、ネットワーク、監視、アップグレードに対して事前に構成されたベスト プラクティスの既定値を提供します。 この記事の大規模なチューニング ガイダンスは、大規模な運用時に AKS Automatic と AKS Standard の両方に引き続き適用されます。

AKS でクラスターをデプロイして管理するときは、次のベスト プラクティスを使って、パフォーマンスとスケーリングを最適化できます。

"大規模" とは相対的な用語であることに注意してください。 Kubernetes には多次元のスケール エンベロープがあり、ワークロードのスケール エンベロープは使用するリソースによって異なります。 たとえば、100 個のノードと数千個のポッドまたは CRD を含むクラスターは、大規模と見なされるかもしれません。 1,000 個のポッドと他のさまざまなリソースを含む 1,000 ノードのクラスターは、コントロール プレーンの観点からは小規模と見なされる可能性があります。 Kubernetes コントロール プレーンのスケールの最もよい判断基準は、API サーバーの HTTP 要求の成功率と待ち時間です。これは、コントロール プレーンでの負荷量の代わりになるものです。

この記事では、次の内容について説明します。

  • 大規模なワークロードに対する AKS クラスター モードのガイダンス。
  • ノードのスケーリング。
  • AKS と Kubernetes コントロール プレーンのスケーラビリティ。
  • バックオフ、ウォッチ、改ページなど、Kubernetes クライアントのベスト プラクティス。
  • Azure API とプラットフォームのスロットリング制限事項。
  • 機能の制限。
  • ネットワークのベスト プラクティス。

大規模なワークロードに対する AKS モードのガイダンス

AKS では、次の 2 つのクラスター モードがサポートされています。

  • AKS Automatic: ほとんどの本番ワークロードに推奨される出発点です。 スケーリング、セキュリティ、ネットワーク、監視、アップグレードにマネージド プラットフォームの既定値を提供することで、運用上のオーバーヘッドを軽減します。
  • AKS Standard: クラスター トポロジ、ネットワーク、自動スケール動作、またはアップグレード オーケストレーションを明示的に制御する必要がある場合に最適です。

この記事の大規模なパフォーマンスとスケーリングのガイダンスは、両方のクラスター モードに適用されます。 AKS Automatic では、プラットフォームの既定値のより多くの部分を AKS 側が担うようになりますが、それでもコントロール プレーンの負荷、クライアントの動作、スロットリング、ネットワークの制限、アップグレードの余裕を理解する必要がなくなるわけではありません。

ノードのスケーリング

AKS クラスターを大規模なスケール ポイントにスケーリングするときは、次のノード スケーリングのベスト プラクティスに留意してください。

  • 大規模な AKS クラスターを実行する場合は、可能な限り クラスター オートスケーラー または ノード自動プロビジョニング (NAP) を 使用して、コンピューティング リソースの需要に基づいてノードを動的にスケーリングします。
  • AKS Automatic は、ほとんどの運用ワークロードに推奨される開始点ですが、どちらのクラスター モードの大規模なクラスターでも、ノードのスケーリング、バッチ計画、コントロール プレーンの検証を慎重に行う必要があります。
  • 1,000 ノードを超えてスケーリングし、クラスター オートスケーラーを "使わない" 場合は、一度に 500 から 700 ノードをバッチでスケーリングすることをお勧めします。 スケーリング操作には、Azure API の調整を防ぐために、スケールアップ操作の間に 2 ~ 5 分の待機時間が必要です。
  • システム ノード プールの場合は、Standard_D16ds_v5 SKU または同等のコア/メモリ VM SKU とエフェメラル OS ディスクを使って、kube-system ポッドに十分なコンピューティング リソースを提供するようにします。
  • AKS にはノード プールあたり 1,000 ノードの制限があるため、5,000 ノードまでスケールアップするには、少なくとも 5 つのユーザー ノード プールを作成することをお勧めします。

AKS と Kubernetes コントロール プレーンのスケーラビリティ

Kubernetes では、クラスターで実行されているすべてのオブジェクトは、AKS によって管理されるコントロール プレーンによって管理されます。 AKS は、スケーラビリティとパフォーマンスに関して Kubernetes コントロール プレーンとそのコンポーネントを最適化しますが、それでもアップストリーム プロジェクトの制限による制約を受けます。

これらのコントロール プレーンの制限と API の使用パターンは、AKS Automatic と AKS Standard の両方に適用されます。 AKS Automatic は運用オーバーヘッドを削減しますが、コントロール プレーンには有限の容量があり、大規模な効率的なワークロード動作が必要です。

Kubernetes には多次元のスケール エンベロープがあり、各リソースの種類はディメンションを表し、すべてのリソースがコストに等しいわけではありません。 たとえば、シークレットは多くの場合、複数のコントローラーとポッドによって監視され、それぞれが最初の LIST 呼び出しを行って状態を同期します。 シークレットは通常、大規模で頻繁に更新されるため、監視頻度の低いリソースよりもコントロール プレーンへの負荷が高くなります。

特定のディメンション内でクラスターをスケーリングするほど、他のディメンション内でスケーリングできるスケールは小さくなります。 たとえば、AKS クラスターで数十万個のポッドを実行すると、コントロール プレーンでサポートできるポッドのチャーン (1 秒間にポッドが変化する回数) の量に影響します。

AKS では、基本 SKU の一部として、Free、Standard、Premium の 3 つのコントロール プレーン価格レベルがサポートされています。 詳しくは、AKS クラスター管理での Free、Standard、Premium の価格レベルに関する記事をご覧ください。

重要

運用環境または大規模なワークロードには、Standard または Premium の価格レベルを使用します。 AKS では、次のスケール制限に対応するために、Kubernetes コントロール プレーンが自動的にスケールアップされます。

  • AKS クラスターあたり最大 5,000 ノード
  • AKS クラスターあたり 200,000 ポッド (Azure CNI オーバーレイを使用)

ほとんどの場合、スケール制限のしきい値を超えるとパフォーマンスが低下しますが、クラスターがすぐにフェールオーバーすることはありません。 Kubernetes コントロール プレーンでの負荷を管理するには、現在のスケールの最大 10% から 20% のスケーリングをバッチで行うことを検討してください。 たとえば、5,000 ノードのクラスターの場合は、500 から 1,000 ノードの増分でスケーリングします。 AKS はコントロール プレーンを自動スケーリングしますが、即座に行われるわけではありません。

コントロール プレーンがスケールアップされているかどうかを確認するには、configmap large-cluster-control-plane-scaling-statusを探します。

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Kubernetes スケール エンベロープとコントロール プレーンに関する考慮事項

Kubernetes クライアントは、オペレーターや監視エージェントなどのアプリケーション コンポーネントであり、クラスターで実行され、kube-apiserver と通信してリソースの読み取りまたは変更を行います。 これらのクライアントの動作を最適化して、kube-apiserver と Kubernetes コントロール プレーンに配置される負荷を軽減することが重要です。

AKS Automatic では、効率的なクライアント動作の必要性は排除されません。大規模なクラスターでは、引き続きウォッチベースのパターン、改ページ、バックオフ、および制限付き LIST トラフィックが必要です。

特定の時点で API サーバーによってアクティブに処理される要求の数は、 --max-requests-inflight フラグと --max-mutating-requests-inflight フラグによって決まります。 AKS では、これらのフラグに対して既定値の 400 要求と 200 要求が使用され、特定の時点で合計 600 件の要求がディスパッチされます。 API サーバーを大きなサイズにスケーリングする場合は、それに応じてインフライト要求も増やします。

PriorityLevelConfiguration と FlowSchema (APF) の 2 種類の Kubernetes オブジェクトは、API サーバーが要求の種類間で要求の合計容量を分割する方法を決定します。 AKS では、既定の構成が使用されます。

各 PriorityLevelConfiguration には、許可された要求の合計の共有が割り当てられます。 クラスター内の PriorityLevelConfiguration オブジェクトとその割り当てられた要求共有を表示するには、次のコマンドを実行します。

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema は、API サーバー要求を PriorityLevelConfiguration にマップします。 複数の FlowSchema オブジェクトが要求と一致する場合、API サーバーは一致する優先順位が最も低いものを選択します。

FlowSchemas から PriorityLevelConfigurations へのマッピングは、次のコマンドを使用して表示できます。

kubectl get flowschemas

APF が原因で要求がドロップされているかどうかを確認するには、次のコマンドを実行します。

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Kubernetes クライアントのベスト プラクティス

最適化されていないクライアントによって発行される LIST 呼び出しは、多くの場合、クラスターのスケーラビリティを制限する最大の要因の 1 つです。 数千を超える小さなオブジェクトまたは数百を超える大きなオブジェクトを含むリストを操作するときは、次のガイドラインを考慮する必要があります。

  • 新しいリソースの種類 (CRD) を定義するときに、最終的に存在することが予想されるオブジェクト (CR) の数を検討します。
  • etcd および API サーバーの負荷は、主に応答のサイズに依存します。 このガイダンスは、クライアントが大きなオブジェクトに対して少数の LIST 要求を発行するか、小さいオブジェクトに対して多数の LIST 要求を発行するかを適用します。

インフォーマーを使用する

  • コードでメモリ内のオブジェクトの更新されたリストを維持する必要がある場合は、クライアントゴー ライブラリの インフォーマー を使用すると、変更をポーリングするのではなく、イベントに基づいてリソースへの変更を監視する利点があります。 最適化されていない LIST や繰り返し LIST を回避するには、この方法が最適です。

API サーバー キャッシュを使用する

resourceVersion=0を使用して、API サーバー キャッシュから結果を返します。 これにより、オブジェクトが etcd からフェッチされるのを防ぎ、etcd の読み込みを減らすことができます が、改ページ処理はサポートされません。

/api/v1/namespaces/default/pods?resourceVersion=0

効率的な Kubernetes API の使用

可能な限り watch 引数を使用することをお勧めします。 引数を指定しない場合の既定の動作は、オブジェクトを一覧表示することです。 例えば次が挙げられます。

/api/v1/namespaces/default/pods?watch=true

先行する list または watch から受け取った最新の既知の値を resourceVersion に設定して、watch を使用します。 これはクライアントゴーで自動的に処理されます。 ただし、他の言語で Kubernetes クライアントを使用しているかどうかを確認します。

/api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>

コントローラーまたはオペレーターが LIST 呼び出しを使用する必要がある場合は、特に大規模なクラスターでは、ラベルまたはフィールド セレクターを使用せずにクラスター全体のリソースをポーリングしないようにする必要があります。 次の例は、最適化された LIST 呼び出しと最適化されていない LIST 呼び出しを示しています。

  • 最適化されたリスト:

    /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running

  • 最適化されていない LIST:

    /api/v1/pods

クライアントが etcd からデータをフェッチする必要がある場合は、改ページを使用して LIST 応答のサイズを小さくします。 次の例では、limit 引数を使用して、応答を 100 個のオブジェクトに制限します。

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100

上記の例のすべてのポッド オブジェクトを引き続き LIST から返す場合は、制限付きの continue 引数を使用します。

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>

kubectl を使用している場合は、 --chunk-size 引数をページ分割応答に直接適用できます。

kubectl get pods -n default --chunk-size=100

コントローラーまたはオペレーターがリーダー選定にリース更新プログラムを使用する場合は、ワークロードに最適な leaseDuration、 renewDeadline、および retryPeriod を調整することで、一時的な接続の問題に対する回復性があることを確認します。 クライアントゴー リーダーの選択を使用する Kubernetes コントローラーの場合は、次の式を使用します。

lease_duration > renew_deadline > retry_period

Daemonsets（デーモンセット）

  • 1 つのコントローラー リスト オブジェクトと、同じことを行うすべてのノードで実行されている DaemonSet には大きな違いがあります。 クライアント アプリケーションの複数のインスタンスが定期的に多数のオブジェクトを一覧表示する場合、ソリューションは大規模なクラスターでは適切にスケーリングされません。

  • 何千ものノードがあるクラスターでは、新しい DaemonSet を作成したり、DaemonSet を更新したり、ノードの数を増やしたりすると、コントロール プレーンに負荷が高くなる可能性があります。 DaemonSet ポッドがポッドの起動時にコストの高い API サーバー要求を発行すると、多数の同時要求からコントロール プレーンでリソースの使用率が高くなる可能性があります。

  • RollingUpdate 戦略を使用して、新しい DaemonSet ポッドを段階的にロールアウトします。 DaemonSet テンプレートが更新されると、コントローラーは古いポッドを制御された方法で新しいポッドに置き換えます。 ローリング 更新戦略が明示的に構成されていない場合、Kubernetes は既定で maxUnavailable を 1、maxSurge を 0、minReadySeconds を 0 に設定した RollingUpdate を作成します。 次の例を参照してください。

      minReadySeconds: 30
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1

  • RollingUpdate 戦略は、既存の DaemonSet ポッドにのみ適用されます。 新しいノードを追加したり、追加の DaemonSet ポッドを作成したり、まったく新しい DaemonSet をデプロイしたりする影響は制限されません。

  • ノードのスケールアウトまたは新しい DaemonSet デプロイ後の起動時に DaemonSet が API サーバーに同時 LIST 要求を発行しないようにするには、コンテナー エントリポイントにスタートアップ ジッターを実装し、5xx または 429 応答の適切な 指数バックオフ と 再試行ポリシー を構成して、大きな LIST 要求の再試行を繰り返さないようにします。

      spec:
    template:
      spec:
        containers:
        - name: my-daemonset-container
          image: <image>
          command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]

注記

Kube 監査ログを使用し、API サーバーのトラフィックとクライアントの動作を分析できます。 詳しくは、Kubernetes コントロール プレーンのトラブルシューティングに関する記事をご覧ください。

etcd の最適化

  • etcd 全体のサイズを小さくし、汎用データベースとして etcd を使用しないでください。 AKS では既定で 8 GB の etcd ストレージが提供されますが、etcd データベースが大きいほど最適化時間が長くなり、読み取りと書き込みのパフォーマンスの問題が発生する可能性があります。 etcd データベースが大きくなると、最適化されていないクライアントが etcd から多数のオブジェクトを頻繁にフェッチする場合に、API サーバーと etcd の信頼性の問題の確率が高くなる可能性もあります。 etcd データベースのサイズが 2 GB を超える場合は、以下に示すオブジェクト サイズの縮小手法を使用することを検討してください。
  • ポッド仕様のサイズを小さくするには、環境変数をポッドの仕様から ConfigMaps に移動します。
  • 大きなシークレットまたは ConfigMap を、より小さく管理しやすい部分に分割します。
  • 可能な場合は、Kubernetes シークレットの代わりに Azure Key Vault にシークレットを格納して、etcd に格納されるシークレットの数を減らします。
  • 未使用のオブジェクトをクリーンアップする
    • 古いジョブと完了したポッドを削除します。 終了したオブジェクトが自動的に削除されるように、ジョブで ttlSecondsAfterFinished を使用します。
    • コントローラーが ownerReferences を設定していることを確認します。 これにより、Kubernetes ガベージ コレクションは、親リソースが削除されたときに依存オブジェクトを自動的に削除できます。
    • successfulJobsHistoryLimit と failedJobsHistoryLimit を設定して、完了したジョブ レコードの数を少なくして CronJob 履歴を制限します。
    • デプロイのロールアウト履歴を減らします。 古い ReplicaSet も API オブジェクトとして格納されます。 既定値は 10 です。
  • --history-max引数を使用して Helm リビジョン履歴を減らします。 大規模なクラスターでは、5 未満にしてください。

AKS コントロール プレーンのメトリックとログを監視する

大規模な AKS クラスターでコントロール プレーンのメトリックを監視することは、Kubernetes ワークロードの安定性とパフォーマンスを確保するために重要です。 これらのメトリックは、API サーバー、etcd、コントローラー マネージャー、スケジューラなどの重要なコンポーネントの正常性と動作を可視化します。 リソースの競合と大量の API 呼び出しが一般的である大規模な環境では、コントロール プレーンのメトリックを監視することでボトルネックを特定し、異常を検出し、リソース使用量を最適化することができます。 これらのメトリックを分析することで、オペレーターは API サーバーの待機時間、高い etcd オブジェクト、過剰なコントロール プレーン リソース消費などの問題に事前に対処し、効率的なクラスター運用を確保し、ダウンタイムを最小限に抑えることができます。

AKS 自動では運用上のオーバーヘッドが削減されますが、ワークロードが大きい場合でも、コントロール プレーンの正常性、要求の待機時間、etcd の負荷を同じ可視性で把握する必要があります。

Azure Monitorでは、Azure Managed Prometheus と Diagnostic settings を通じてコントロール プレーンの正常性に関する包括的なメトリックとログが提供されます。

主要なコントロール プレーン プラットフォームのメトリック

AKS は、API サーバーと etcd の正常性を監視するために、Azure Monitorで次のプラットフォーム メトリックを公開します。 これらのメトリックは、Managed Prometheus を有効にせずに使用でき、AKS クラスターの Metrics のAzure ポータルで直接表示できます。

API Server メトリック:

メトリクス 説明
apiserver_cpu_usage_percentage インスタンス間で API サーバー ポッドによって使用される最大 CPU 使用率 (現在の制限に基づく)。
apiserver_memory_usage_percentage インスタンス間で API サーバー ポッドによって使用されるメモリの最大割合 (現在の制限に基づく)。
apiserver_current_inflight_requests (プレビュー) 要求の種類ごとに、API サーバー上の現在アクティブなインフライト要求の最大数。

Etcd メトリック:

メトリクス 説明
etcd_cpu_usage_percentage インスタンス間で etcd ポッドによって使用される最大 CPU 使用率 (現在の制限に基づく)。
etcd_memory_usage_percentage インスタンス間で etcd ポッドによって使用されるメモリの最大割合 (現在の制限に基づく)。
etcd_database_usage_percentage インスタンス間での etcd データベースの最大使用率。 etcd ストレージの上限を超えないように、これを注意深く監視してください。

API サーバーのリソース負荷を検出するために、 apiserver_cpu_usage_percentage と apiserver_memory_usage_percentage を一貫して監視します。 etcd_database_usage_percentageが一貫して 50%を超えている場合は、「Etcd Optimizations」セクションを確認してデータベース サイズを小さくしてください。 使用可能なメトリックの完全な一覧については、 AKS 監視データリファレンスを参照してください。

機能の制限

AKS クラスターをさらに大きなスケール ポイントにスケーリングするときは、機能に関する次の制限に注意してください。

  • AKS では、すべての Standard レベル/LTS クラスターに対して、既定で最大 5,000 ノードのスケーリングがサポートされています。 AKS は、クラスター サイズと API サーバーのリソース使用率に基づいて、実行時にクラスターのコントロール プレーンをスケーリングします。 サポートされている制限にスケールアップできない場合は、prometheus の Azure Monitor マネージド サービスで control plane metrics (Preview) を有効にして、コントロール プレーンを監視します。 スケーリングのパフォーマンスまたは信頼性に関する問題のトラブルシューティングを支援するには、次のリソースを参照してください。

    注記

    コントロール プレーンをスケーリングする操作中に、API サーバーの待機時間が長くなったり、最大 15 分間のタイムアウトが発生したりする可能性があります。 サポートされている制限へのスケーリングで問題が引き続き発生する場合は、support チケットを開きます。

  • Azure ネットワーク ポリシー マネージャー (Azure npm) は最大 250 個のノードのみをサポートします。

  • ノード ディスク使用量、ノード CPU/メモリ使用量、ネットワークイン/アウトなど、一部の AKS ノード メトリックは、コントロール プレーンのスケールアップ後>Azure監視プラットフォーム メトリック

  • ノード数が 100 を超えるクラスターでは、停止および開始機能を使用できません。 詳しくは、「Azure Kubernetes Service (AKS) クラスターの停止と起動」をご覧ください。

Azure API とプラットフォームのスロットリング

クラウド アプリケーションに対する負荷は、アクティブなユーザーの数や、ユーザーが実行するアクションの種類などの要因に応じて、時間と共に変化する場合があります。 システムの処理要件が利用できるリソースの容量を超えると、システムが過負荷になり、パフォーマンスが低下したり、障害が発生したりする可能性があります。

AKS Automatic ではクラスター運用が簡素化されますが、大規模環境では Azure サブスクリプションとプラットフォームのスロットリング制限が引き続き適用されます。

クラウド アプリケーションでの負荷の大きさの変化に対処するには、指定した制限まではアプリケーションによるリソースの使用を許可し、制限に達したらスロットルすることができます。 Azureでは、スロットリングは 2 つのレベルで行われます。 Azure Resource Manager (ARM) は、サブスクリプションとテナントの要求を調整します。 要求がサブスクリプションとテナントのスロットリング制限を下回っている場合、ARM は要求をリソース プロバイダーにルーティングします。 その後、リソース プロバイダーによって、その操作に合わせて調整されたスロットリング制限が適用されます。 詳細については、「ARM 調整要求」を参照してください。

AKS でのスロットリングを管理する

Azure API の制限は、通常、サブスクリプションリージョンの組み合わせレベルで定義されます。 たとえば、特定のリージョン内のサブスクリプション内のすべてのクライアントは、VIRTUAL MACHINE SCALE SETS PUT API など、特定のAzure API の API 制限を共有します。 すべての AKS クラスターには、クラウド プロバイダーやクラスター オートスケーラーなどの複数の AKS 所有クライアント、または Datadog やセルフホステッド Prometheus などの顧客所有のクライアントがあり、Azure API を呼び出します。 特定のリージョン内の 1 つのサブスクリプションで複数の AKS クラスターを実行すると、そのクラスター内の AKS 所有と顧客所有のすべてのクライアントが、共通の API 制限のセットを共有します。 そのため、サブスクリプションのリージョンにデプロイできるクラスターの数は、デプロイされるクライアントの数、その呼び出しパターン、クラスターの全体的なスケールと弾力性の関数になります。

上記の考慮事項に留意し、お客様は通常、サブスクリプションとリージョンの組み合わせごとに 20 から 40 個の小規模から中規模のクラスターをデプロイできます。 サブスクリプションのスケールは、次のベスト プラクティスを使って最大化できます。

Kubernetes クラスターを常に最新バージョンにアップグレードします。 バージョンが新しいほど、パフォーマンスとスロットリングの問題に対処する多くの機能強化が組み込まれています。 アップグレードされたバージョンの Kubernetes を使っていて、それでもまだ、実際の負荷またはサブスクリプション内のクライアント数によってスロットリングが発生する場合は、次のオプションを試すことができます。

  • AKS の問題の診断と解決を使用してエラーを分析する: AKS の診断と解決の問題 を使用して、エラーを分析し、根本原因を特定し、解決に関する推奨事項を取得できます。
    • クラスター オートスケーラーのスキャン間隔を増やす: 診断レポートで クラスター オートスケーラーのスロットリングが検出されたことが示された場合、スキャン間隔を増やすことで、クラスター オートスケーラーからの仮想マシン スケールセットへの呼び出しを減らすことができます。
    • サード パーティ製アプリケーションを再構成して呼び出し回数を減らす: View request rate and throttle details (ビューの要求レートとスロットルの詳細) 診断で "ユーザー エージェント" によってフィルター処理し、監視アプリケーションなどのサード パーティ製アプリケーションが大量の GET 要求を行っていることがわかった場合は、これらのアプリケーションの設定を変更して、GET 呼び出しの頻度を減らすことができます。 Azure API を呼び出すときに、アプリケーション クライアントで指数バックオフが使用されていることを確認します。
  • クラスターを異なるサブスクリプションまたはリージョンに分割する: Virtual Machine Scale Setsを使用する多数のクラスターとノード プールがある場合は、それらを同じサブスクリプション内の異なるサブスクリプションまたはリージョンに分割できます。 ほとんどのAzure API の制限はサブスクリプション リージョン レベルで共有されるため、クラスターを別のサブスクリプションまたはリージョンに移動またはスケーリングして、Azure API 調整のブロックを解除できます。 このオプションは、クラスターのアクティビティが高いことが予想される場合に特に役立ちます。 これらの制限に関する一般的なガイドラインはありません。 具体的なガイダンスが必要な場合は、サポート チケットを作成できます。

ネットワーク

AKS クラスターをさらに大きなスケール ポイントにスケーリングするときは、ネットワークに関する次のベスト プラクティスに留意してください。

  • NAT ゲートウェイ上に少なくとも 2 つのパブリック IP があるクラスター エグレスに対して、マネージド NAT を使います。 詳しくは、AKS クラスターに対するマネージド NAT ゲートウェイの作成に関する記事をご覧ください。

  • AKS Automatic ではマネージド ネットワークの既定値が提供されますが、大規模なワークロードをスケーリングする場合は、送信パス、DNS の動作、ロード バランサーの制限、サービス トポロジを検証する必要があります。

  • Azure Standard Load Balancerを使用している場合は、少なくとも 2 送信パブリック IP を使うようにしてください。 また、大規模なクラスターを計画する場合は、LoadBalancer サービスバックエンドルールの制限も考慮してください。 Azure Standard Load Balancer では、フロントエンド IP あたり最大 10,000 個のバックエンド IP 構成がサポートされます。 各種類: LoadBalancer サービスは、公開されたポートごとに 1 つの負荷分散規則を作成し、すべてのクラスター ノードをロード バランサー バックエンド プールに関連付けます。 たとえば、1 つのサービスに対して 5 つのポートを公開すると、2000 ノードでこの制限に達します。

    1 service * 5 ports * 2000 nodes = 10000 backend IP configurations

  • Azure CNI オーバーレイを使用して、クラスターあたり最大 200,000 ポッドと 5,000 ノードをスケールアップします。 詳細については、「AKS での CNI オーバーレイ ネットワークAzure構成を参照してください。

  • アプリケーションでクラスター間のポッド間の直接通信が必要な場合は、動的 IP 割り当てで Azure CNI を使用し、ポッドごとに 1 つのルーティング可能な IP を持つクラスターあたり最大 50,000 個のアプリケーション ポッドをスケールアップします。 詳細については、「AKS での動的 IP 割り当てのための CNI ネットワークAzure構成を参照してください。

  • 内部ロード バランサーの内側で内部 Kubernetes サービスを使う場合は、スケーリングのパフォーマンスとロード バランサーの弾力性を最適にするため、作成する内部ロード バランサーまたはサービスのノード スケールを 750 未満にすることをお勧めします。

  • Azure ネットワーク ポリシー マネージャー (NPM) は、最大 250 個のノードのみをサポートします。 大規模なクラスターに対してネットワーク ポリシーを適用する場合は、Cilium を利用する Azure CNI を使用することを検討してください。これは、Azure CNI の堅牢なコントロール プレーンと Cilium データ プレーンを組み合わせて、高パフォーマンスのネットワークとセキュリティを提供します。

  • ノード プールで LocalDNS を有効にして、DNS 解決の待機時間を短縮し、一元化された CoreDNS ポッドをオフロードします。 DNS クエリ ボリュームが多い大規模なクラスターでは、一元化された DNS 解決がボトルネックになる可能性があります。 LocalDNS では、各ノードに DNS プロキシを systemd サービスとしてデプロイし、クエリをローカルで解決し、テーブル conntrack 負荷を排除し、TCP への接続をアップグレードして競合状態 conntrack 回避します。 LocalDNS では、アップストリーム DNS が使用できない場合に古いキャッシュされた応答を提供することもサポートされており、一時的な障害時のワークロードの回復性が向上します。 詳細については、「 AKS での DNS 解決」を参照してください。

クラスターのアップグレードに関する考慮事項とベスト プラクティス

AKS Automatic はアップグレード ライフサイクルの多くを自動的に処理しますが、このセクションの最大サージと容量計画のガイダンスは、特に中断を調整して十分なヘッドルームを確保する場合に、大規模なワークロードでは依然として重要です。

AKS クラスターを大規模なスケール ポイントにスケーリングするときは、次のクラスター アップグレードのベスト プラクティスに留意してください。

  • クラスターがノード制限 5,000 に達すると、クラスターのアップグレードはブロックされます。 この制限により、最大サージ プロパティ制限内でローリング更新を実行するために使用可能なノード容量がないため、アップグレードが妨げられます。 この制限でクラスターがある場合、クラスターのアップグレードを試みる前に、3,000 ノード未満にクラスターをスケールダウンすることをお勧めします。 これにより、ノード チャーンに容量が追加され、コントロール プレーンの負荷が最小限に抑えられます。
  • ノード数が 500 を超えるクラスターをアップグレードする場合は、ノード プールの容量の 最大サージ構成 として 10 から 20% を使用することをお勧めします。 AKS では、最大サージに対して既定値の 10% でアップグレードを構成します。 最大サージ設定をノード プールごとにカスタマイズすることで、アップグレードの速度とワークロードによる中断とのトレードオフが可能になります。 最大サージ設定を大きくするとアップグレード プロセスはより速く完了しますが、アップグレード プロセス中に中断が発生する可能性があります。 詳細については、「ノード サージ アップグレードのカスタマイズ」を参照してください。
  • 詳細については、「AKS クラスターのアップグレード」を参照してください。

関連するコンテンツ

  • 最終更新: