Container Service for Kubernetes:負荷ベースのホットスポットデスケジューリングの使用

制限事項

• ACK マネージド版 Pro クラスター のみがサポートされています。

• 関連コンポーネントは、次のバージョン要件を満たす必要があります。

  コンポーネント	バージョン要件
  ACK Scheduler	v1.22.15-ack-4.0 以降、v1.24.6-ack-4.0 以降
  ack-koordinator	v1.1.1-ack.1 以降
  Helm	v3.0 以降

課金

ack-koordinator コンポーネントは無料でインストールして使用できます。ただし、次のシナリオでは追加料金が発生する場合があります：

• ack-koordinator は自己管理コンポーネントであり、インストール後にワーカーノードのリソースを消費します。コンポーネントのインストール時に、各モジュールのリソースリクエストを設定できます。

• デフォルトでは、ack-koordinator はリソースプロファイリングや詳細なスケジューリングなどの機能のモニタリングメトリックを Prometheus 形式で公開します。コンポーネントの設定時に [ACK-Koordinator の Prometheus モニタリングを有効にする] オプションを選択し、Alibaba Cloud Prometheus サービスを使用する場合、これらのメトリックはカスタムメトリックと見なされ、料金が発生します。料金は、クラスターのサイズやアプリケーションの数などの要因によって異なります。この機能を有効にする前に、Alibaba Cloud Prometheus の「Prometheus インスタンスの課金」ドキュメントをよく読み、カスタムメトリックの無料クォータと課金ポリシーを理解してください。使用量データをクエリすることで、リソース使用量を監視および管理できます。

負荷ホットスポットデスケジューリングの概要

負荷認識スケジューリング

ACK スケジューラは負荷認識スケジューリングをサポートしており、負荷の低いノードに Pod をスケジュールできます。クラスター環境、トラフィック、リクエストが変化するため、ノード使用率も動的に変化します。これにより、クラスター内のノード間の負荷バランスが崩れ、深刻な負荷の不均衡が生じることさえあります。これは、ワークロードのランタイム品質に影響します。ack-koordinator は、ノード負荷の変化を識別し、安全な負荷しきい値を超えるノードから Pod を自動的にデスケジュールして、深刻な負荷の不均衡を防ぐことができます。負荷認識スケジューリングとホットスポットデスケジューリングを組み合わせることで、ノード間の最適な負荷分散を実現できます。詳細については、「負荷認識 Pod スケジューリングの使用」をご参照ください。

Koordinator Descheduler モジュールの仕組み

ack-koordinator コンポーネントは、Koordinator Descheduler モジュールを提供します。このモジュールでは、LowNodeLoad プラグインが負荷レベルを検出し、負荷ベースのホットスポットデスケジューリングを実行します。ネイティブ Kubernetes Descheduler の LowNodeUtilization プラグインとは異なり、LowNodeLoad プラグインはノードの実際のリソース使用率に基づいてデスケジューリングを決定しますが、LowNodeUtilization プラグインはリソース割り当て率に基づいて決定します。

実行手順

Koordinator Descheduler モジュールは定期的に実行されます。各実行サイクルは、次の 3 つのステージで構成されます。

1. データ収集：クラスター内のノードとワークロード、およびそれらに関連するリソース使用率に関する情報を取得します。

2. ポリシープラグインの実行。

   次のステップでは、LowNodeLoad プラグインを例として使用します。

   1. ホットスポットノードを識別します。ノードの分類の詳細については、「LowNodeLoad 負荷しきい値パラメーター」をご参照ください。

   2. すべてのホットスポットノードを走査し、移行可能な Pod を識別してソートします。Pod のスコアリングとソートの詳細については、「Pod スコアリングポリシー」をご参照ください。

   3. 移行対象のすべての Pod を走査し、クラスターサイズ、リソース使用率、複製された Pod の比率などの制約に基づいて、Pod が移行の要件を満たしているかどうかを確認します。詳細については、「負荷認識ホットスポットデスケジューリングポリシー」をご参照ください。

   4. Pod が条件を満たす場合、移行対象のレプリカとして分類されます。そうでない場合、プロセスは他の Pod とホットスポットノードの走査を続行します。

3. Pod のエビクションと移行: 移行の要件を満たす Pod をエビクションします。詳細については、「API によって開始されるエビクション」をご参照ください。

LowNodeLoad 負荷しきい値パラメーター

たとえば、次の図では、lowThresholds は 45% に設定され、highThresholds は 70% に設定されています。ノードは次の基準に基づいて分類されます。同様に、lowThresholds と highThresholds の値が変更されると、ノードの分類基準もそれに応じて変更されます。

デフォルトでは、リソース使用率データは 1 分ごとに更新されます。粒度は過去 5 分間の平均値です。

• アイドルノード：リソース使用率が 45% 未満のノード。

• 通常ノード：リソース使用率が 45% 以上 70% 以下のノード。この負荷レベルが望ましい範囲です。

• ホットスポットノード：リソース使用率が 70% を超えるノード。ホットスポットノード上の一部の Pod は、負荷レベルを 70% 以下に下げるためにエビクションされます。

負荷ホットスポットデスケジューリングポリシー

kubectl get event | grep stress-demo-588f9646cf-7****
55s         Normal    Evicting           podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
22s         Normal    EvictComplete      podmigrationjob/3bf8f623-4d10-4fc5-ab4e-2bead3c4****   Pod "default/stress-demo-588f9646cf-7****" has been evicted
55s         Normal    Descheduled        pod/stress-demo-588f9646cf-7****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(76.72%)>threshold(50.00%)"
55s         Normal    Killing            pod/stress-demo-588f9646cf-7****                       Stopping container stress

ステップ 1: ack-koordinator でのデスケジューリングの有効化

• クラスターに ack-koordinator コンポーネントがインストールされていない場合は、コンポーネントをインストールし、コンポーネント設定ページで [ack-koordinator のデスケジューリングを有効にする] を選択します。詳細については、「ack-koordinator コンポーネントのインストール」をご参照ください。

• クラスターに ack-koordinator コンポーネントが既にインストールされている場合は、コンポーネント設定ページで [ack-koordinator のデスケジューリングを有効にする] を選択します。手順については、「ack-koordinator コンポーネントの変更」をご参照ください。

ステップ 2: 負荷ホットスポットデスケジューリングプラグインの有効化

1. 次の YAML コンテンツを使用して `koord-descheduler-config.yaml` ファイルを作成します。

   `koord-descheduler-config.yaml` ファイルは、LowNodeLoad デスケジューリングプラグインを有効にするために使用される ConfigMap オブジェクトです。

   クリックして YAML ファイルの内容を表示します

   # koord-descheduler-config.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: koord-descheduler-config
     namespace: kube-system
   data:
     koord-descheduler-config: |
       # 以下の内容は koord-descheduler のシステム設定です。設定を変更しないでください。
       apiVersion: descheduler/v1alpha2
       kind: DeschedulerConfiguration
       leaderElection:
         resourceLock: leases
         resourceName: koord-descheduler
         resourceNamespace: kube-system
       deschedulingInterval: 120s # 実行間隔。デスケジューリングプラグインは 120 秒ごとに実行されます。
       dryRun: false # グローバル読み取り専用モードのスイッチ。このモードを有効にすると、Koordinator Descheduler は何も操作を実行しません。
       # システム設定の終わり。
   
       profiles:
       - name: koord-descheduler
         plugins:
           balance:
             enabled:
               - name: LowNodeLoad # 負荷ホットスポットデスケジューリングのために LowNodeLoad プラグインを有効にします。
           evict:
             enabled:
               - name: MigrationController # エビクションおよび移行コントローラーを有効にします。
   
         pluginConfig:
         - name: MigrationController # デスケジューリングおよび移行制御のパラメーター。
           args:
             apiVersion: descheduler/v1alpha2
             kind: MigrationControllerArgs
             defaultJobMode: EvictDirectly
   
         - name: LowNodeLoad # LowNodeLoad プラグインの設定。
           args:
             apiVersion: descheduler/v1alpha2
             kind: LowNodeLoadArgs
   
             lowThresholds:  # lowThresholds はアイドルノードの受付しきい値を指定します。すべてのリソースの使用率がしきい値を下回る場合、ノードはアイドルと見なされます。
               cpu: 20 # CPU 使用率は 20% です。
               memory: 30  # メモリ使用率は 30% です。
             highThresholds: # highThresholds はホットスポットノードの受付しきい値を指定します。いずれかのリソースの使用率がしきい値を超える場合、ノードはホットスポットと見なされます。
               cpu: 50  # CPU 使用率は 50% です。
               memory: 60 # メモリ使用率は 60% です。
   
             evictableNamespaces: # デスケジュール可能な名前空間。include と exclude パラメーターは相互排他的です。どちらか一方のみを設定できます。
               include: # include パラメーターは、以下の名前空間のみを処理することを指定します。
                 - default
               # exclude: # exclude パラメーターは、除外する名前空間を指定します。
                 # - "kube-system"
                 # - "koordinator-system"

2. 次のコマンドを実行して、設定をクラスターに適用します。

   kubectl apply -f koord-descheduler-config.yaml

3. 次のコマンドを実行して、Koordinator Descheduler モジュールを再起動します。

   Koordinator Descheduler モジュールを再起動すると、Koordinator Descheduler は最後に変更された設定を使用します。

   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 0
   deployment.apps/ack-koord-descheduler scaled
   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 1
   deployment.apps/ack-koord-descheduler scaled

ステップ 3 (任意): スケジューラ負荷分散プラグインの有効化

ノード間の最適な負荷分散のためにスケジューラ負荷分散プラグインを有効にするには、「ステップ 1: 負荷認識スケジューリングの有効化」をご参照ください。

ステップ 4: デスケジューリング機能の検証

次の例では、それぞれ 104 コアと 396 GiB のメモリを持つ 3 つのノードがあるクラスターを使用します。

1. 次の YAML コンテンツを使用して `stress-demo.yaml` ファイルを作成します。

   クリックして YAML ファイルの内容を表示します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: stress-demo
     namespace: default
     labels:
       app: stress-demo
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: stress-demo
     template:
       metadata:
         name: stress-demo
         labels:
           app: stress-demo
       spec:
         containers:
           - args:
               - '--vm'
               - '2'
               - '--vm-bytes'
               - '1600M'
               - '-c'
               - '2'
               - '--vm-hang'
               - '2'
             command:
               - stress
             image: polinux/stress
             imagePullPolicy: Always
             name: stress
             resources:
               limits:
                 cpu: '2'
                 memory: 4Gi
               requests:
                 cpu: '2'
                 memory: 4Gi
         restartPolicy: Always

2. ストレステスト Pod を作成します。

   kubectl create -f stress-demo.yaml
   deployment.apps/stress-demo created

3. Pod が実行中になるまでステータスを監視します。

   kubectl get pod -o wide

   期待される出力：

   NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE                    NOMINATED NODE   READINESS GATES
   stress-demo-588f9646cf-s****   1/1     Running   0          82s   10.XX.XX.53   cn-beijing.10.XX.XX.53   <none>           <none>

   出力は、Pod stress-demo-588f9646cf-s**** がノード cn-beijing.10.XX.XX.53 にスケジュールされたことを示しています。

4. ノード cn-beijing.10.XX.XX.53 の負荷レベルを上げ、各ノードの負荷を確認します。

   kubectl top node

   期待される出力：

   NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.10.XX.XX.215   17611m       17%    24358Mi         6%
   cn-beijing.10.XX.XX.53    63472m       63%    11969Mi         3%

   出力は、ノード cn-beijing.10.XX.XX.53 の負荷が 63% と高く、設定されたホットスポットしきい値の 50% を超えていることを示しています。ノード cn-beijing.10.XX.XX.215 の負荷は 17% と低く、設定されたアイドルしきい値の 20% を下回っています。

5. 負荷認識ホットスポットデスケジューリングを有効にします。詳細については、「ステップ 2: 負荷ベースのホットスポットデスケジューリングプラグインの有効化」をご参照ください。

6. Pod の変更を監視します。

   Descheduler がホットスポットノードをチェックし、エビクションと移行を実行するのを待ちます。

   説明

   デフォルトでは、ノードが 5 回連続でホットスポットしきい値を超えた場合にホットスポットとして識別され、これには 10 分かかります。

   kubectl get pod -w

   期待される出力：

   NAME                           READY   STATUS               RESTARTS   AGE     IP           NODE                     NOMINATED NODE   READINESS GATES
   stress-demo-588f9646cf-s****   1/1     Terminating          0          59s   10.XX.XX.53    cn-beijing.10.XX.XX.53     <none>           <none>
   stress-demo-588f9646cf-7****   1/1     ContainerCreating    0          10s   10.XX.XX.215   cn-beijing.10.XX.XX.215    <none>           <none>

7. イベントを監視します。

   kubectl get event | grep stress-demo-588f9646cf-s****

   期待される出力：

   2m14s       Normal    Evicting            podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
   101s        Normal    EvictComplete       podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb****   Pod "default/stress-demo-588f9646cf-s****" has been evicted
   2m14s       Normal    Descheduled         pod/stress-demo-588f9646cf-s****                       Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)"
   2m14s       Normal    Killing             pod/stress-demo-588f9646cf-s****                       Stopping container stress

   期待される出力は移行レコードであり、結果が期待通りであることを示しています。ホットスポットノード上の Pod は別のノードにデスケジュールされます。

詳細設定

Koordinator Descheduler モジュールの詳細設定パラメーター

Koordinator Descheduler のすべてのパラメーター設定は ConfigMap で提供されます。以下は、負荷ベースのホットスポットデスケジューリングの詳細設定パラメーターの形式を示しています。

# koord-descheduler-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: koord-descheduler-config
  namespace: kube-system
data:
  koord-descheduler-config: |
    # 以下の内容は koord-descheduler のシステム設定です。設定を変更しないでください。
    apiVersion: descheduler/v1alpha2
    kind: DeschedulerConfiguration
    leaderElection:
      resourceLock: leases
      resourceName: koord-descheduler
      resourceNamespace: kube-system
    deschedulingInterval: 120s # 実行間隔。デスケジューリングプラグインは 120 秒ごとに実行されます。
    dryRun: false # グローバル読み取り専用モードのスイッチ。このモードを有効にすると、koord-descheduler は何も操作を実行しません。
    # システム設定の終わり。

    profiles:
    - name: koord-descheduler
      plugins:
        deschedule: 
          disabled:
            - name: "*" # すべてのプラグインはデフォルトで無効になっています。明示的に設定する必要はありません。これはデモンストレーション目的です。
        balance:
          enabled:
            - name: LowNodeLoad # 負荷ホットスポットデスケジューリングのために LowNodeLoad プラグインを有効にします。
        evict:
          disabled:
            - name: "*" # すべてのプラグインはデフォルトで無効になっています。明示的に設定する必要はありません。これはデモンストレーション目的です。
          enabled:
            - name: MigrationController # エビクションおよび移行コントローラーを有効にします。

      pluginConfig:
      - name: MigrationController # デスケジューリングおよび移行制御のパラメーター。
        args:
          apiVersion: descheduler/v1alpha2
          kind: MigrationControllerArgs
          defaultJobMode: EvictDirectly
          maxMigratingPerNode: 1 # 各ノードで移行状態にできる Pod の最大数。
          maxMigratingPerNamespace: 1  # 各名前空間で移行状態にできる Pod の最大数。
          maxMigratingPerWorkload: 1 # 各ワークロード (デプロイメントなど) で移行状態にできる Pod の最大数。
          maxUnavailablePerWorkload: 2 # 各ワークロード (デプロイメントなど) の利用不可能なレプリカの最大数。
          evictLocalStoragePods: false # HostPath または EmptyDir で設定された Pod のデスケジュールを許可するかどうかを指定します。
          objectLimiters:
            workload: # ワークロードレベルでの Pod 移行のスロットリング。デフォルトでは、最初のエビクションから 5 分以内に最大 1 つのレプリカが移行できます。
              duration: 5m
              maxMigrating: 1

      - name: LowNodeLoad # LowNodeLoad プラグインの設定。
        args:
          apiVersion: descheduler/v1alpha2
          kind: LowNodeLoadArgs

          lowThresholds:  # lowThresholds はアイドルノードの受付しきい値を指定します。すべてのリソースの使用率がしきい値を下回る場合、ノードはアイドルと見なされます。
            cpu: 20 # CPU 使用率は 20% です。
            memory: 30  # メモリ使用率は 30% です。
          highThresholds: # highThresholds はホットスポットノードの受付しきい値を指定します。いずれかのリソースの使用率がしきい値を超える場合、ノードはホットスポットと見なされます。
            cpu: 50  # CPU 使用率は 50% です。
            memory: 60 # メモリ使用率は 60% です。

          anomalyCondition: # ホットスポットノードのチェック設定。
            consecutiveAbnormalities: 5 # ノードは、複数の連続した実行サイクルで highThresholds を超えた場合にのみホットスポットとして識別されます。カウンターはホットスポットノードがエビクションされた後にリセットされます。

          detectorCacheTimeout: "5m" # 異常チェックキャッシュのタイムアウト期間。デフォルト値：5 分。この値が deschedulingInterval で指定された実行間隔以上であることを確認してください。

          evictableNamespaces: # デスケジュール可能な名前空間。include と exclude パラメーターは相互排他的です。どちらか一方のみを設定できます。
            include: # include パラメーターは、以下の名前空間のみを処理することを指定します。
              - default
            # exclude: # exclude パラメーターは、除外する名前空間を指定します。
              # - "kube-system"
              # - "koordinator-system"

          nodeSelector: # 指定されたノードのみを処理します。
            matchLabels:
              alibabacloud.com/nodepool-id: np77f520e1108f47559e63809713ce****

          podSelectors: # 一部のタイプの Pod のみを処理します。
          - name: lsPods
            selector:
              matchLabels:
                koordinator.sh/qosClass: "LS"

Koordinator Descheduler のシステム設定

エビクションと移行の制御設定

type MigrationObjectLimiter struct {
    Duration time.Duration `json:"duration,omitempty"`
    MaxMigrating *intstr.IntOrString `json:"maxMigrating,omitempty"`
}

objectLimiters:
  workload:
    duration: 5m
    maxMigrating: 1

LowNodeLoad プラグインの設定

highThresholds:
  cpu: 55 # CPU 使用率のホットスポットしきい値は 55% です。
  memory: 75 # メモリ使用率のホットスポットしきい値は 75% です。

lowThresholds:
  cpu: 25 # CPU 使用率のアイドルしきい値は 25% です。
  memory: 25 # メモリ使用率のアイドルしきい値は 25% です。

evictableNamespaces:
  exclude:
    - "kube-system"
    - "koordinator-system"

type PodSelector struct {
    name     string
    selector metav1.LabelSelector
}

# LS タイプの Pod のみを処理します。
podSelectors:
- name: lsPods
  selector:
    matchLabels:
      koordinator.sh/qosClass: "LS"

よくある質問

ノードの使用率がしきい値に達しても、ノード上の Pod がエビクションされない場合はどうすればよいですか？

この問題は、次の理由で発生する可能性があります。対応するソリューションを参照して問題を解決できます。

Descheduler が頻繁に再起動するのはなぜですか？

Descheduler は、その ConfigMap が無効であるか存在しない場合に頻繁に再起動することがあります。詳細については、「詳細設定」をご参照ください。ConfigMap の内容と形式を確認し、ConfigMap を変更してから Descheduler を再起動してください。Descheduler の再起動方法の詳細については、「ステップ 2: 負荷ベースのホットスポットデスケジューリングプラグインの有効化」をご参照ください。

負荷認識スケジューリングと負荷ホットスポットデスケジューリングを併用するにはどうすればよいですか？

負荷ベースのホットスポットデスケジューリングを有効にすると、ホットスポットノード上の Pod がエビクションされます。ACK スケジューラは、デプロイメントなどの上位コントローラーによって作成された Pod に適切なノードを選択します。最適な負荷分散を実現するために、同時に負荷認識スケジューリングを有効にすることを推奨します。詳細については、「負荷認識スケジューリングの使用」をご参照ください。

負荷認識スケジューリングの loadAwareThreshold パラメーターを、K8s Spot Rescheduler の highThresholds パラメーターと同じ値に設定することを推奨します。詳細については、「スケジューリングポリシー」をご参照ください。ノードの負荷が highThresholds を超えると、K8s Spot Rescheduler はそのノード上の Pod をエビクションします。スケジューラはその後、loadAwareThreshold を使用して、新しい Pod がホットスポットノードにスケジュールされるのを防ぎます。パラメーターを同じ値に設定しない場合、エビクションされた Pod がホットスポットノードに再スケジュールされる可能性があります。この問題は、Pod がスケジュール可能なノードの範囲を指定しているが、利用可能なノードが少なく、これらのノードのリソース使用率が類似している場合に発生しやすくなります。

デスケジューリングが参照する使用率アルゴリズムは何ですか？

Descheduler は一定期間のリソース使用量を継続的に監視し、平均値を計算します。ノードがデスケジュールされるのは、その平均リソース使用量が一定期間 (デフォルトでは 10 分) しきい値を超え続けた場合のみです。メモリについては、オペレーティングシステムがこれらのリソースを再利用できるため、Descheduler の使用量計算ではページキャッシュが除外されます。対照的に、kubectl top node コマンドが返す使用量にはページキャッシュが含まれます。Managed Service for Prometheus を使用して、実際のメモリ使用量を確認できます。