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 は自己管理型コンポーネントであり、インストール後にワーカーノードのリソースを消費します。コンポーネントをインストールする際に、各モジュールのリソース要求を構成してください。

• Prometheus カスタムメトリック: [ACK-Koordinator 向け Prometheus モニタリングを有効にする] を有効にし、Alibaba Cloud Prometheus サービスを使用すると、公開されるメトリックはカスタムメトリックとしてカウントされ、料金が発生します。料金はクラスターサイズとアプリケーション数によって異なります。この機能を有効にする前に、Prometheus インスタンスの課金に関するドキュメントを確認してください。リソース消費量を監視および管理するには、使用状況データを照会してください。

仕組み

実行サイクル

Koordinator Descheduler は定期的に実行されます。各実行サイクルには 3 つのステージがあります:

1. データ収集: ノードおよびワークロードの情報と、それらのリソース使用量データを取得します。

2. プラグイン実行（LowNodeLoad を例として示します）:

   1. highThresholds および lowThresholds を基準としてホットスポットノードを特定します。

   2. すべてのホットスポットノードを走査し、対象となる Pod をスコアリングしてエビクション順に並べ替えます。詳細については、「Pod スコアリングポリシー」をご参照ください。

   3. 候補となる各 Pod を移行制約（クラスター容量、リソース使用量、レプリカ比率制限）に対してチェックします。詳細については、「負荷感知型ホットスポットデスケジューリングポリシー」をご参照ください。

   4. すべてのチェックを通過した Pod を移行候補としてマークし、通過しなかった Pod はスキップします。

3. ポッドのエビクションと移行: エビクション API を使用して移行候補をエビクションします。

ノード分類

LowNodeLoad プラグインは、2 つのしきい値 — lowThresholds（アイドルしきい値）および highThresholds（ホットスポットしきい値）— を基準として、ノードを 3 つのカテゴリに分類します。

例として lowThresholds = 45%、highThresholds = 70% を使用します:

1. アイドルノード: リソース使用量が lowThresholds 未満（< 45%）です。

2. 通常ノード: リソース使用量が lowThresholds と highThresholds の間（45%–70%）です。これは目標範囲です。

3. ホットスポットノード: リソース使用量が highThresholds を超えています（> 70%）。ノード負荷が 70% 以下になるまで Pod がエビクションされます。

リソース使用量データは 1 分ごとに更新され、過去 5 分間の平均値を反映します。

クラスター内のすべてのノードが lowThresholds を超えている場合、全体的なクラスター負荷は高いと見なされます。この状態では、一部のノードが highThresholds を超えていても、Koordinator Descheduler はデスケジューリングを一時停止します。

前提条件

開始する前に、以下の条件を満たしていることを確認してください:

• ACK 管理型 Pro クラスター

• ACK Scheduler v1.22.15-ack-4.0 以降、ack-koordinator v1.1.1-ack.1 以降、および Helm v3.0 以降

手順 1: ack-koordinator でのデスケジューリングの有効化

• 新規インストール: ack-koordinator をインストールし、コンポーネント構成ページで Ack-koordinator のデスケジューリングを有効化を選択します。詳細については、「ack-koordinator コンポーネントのインストール」をご参照ください。

• 既存のインストール: コンポーネント構成ページで Ack-koordinator のデスケジューリングを有効化を選択します。詳細については、「ack-koordinator コンポーネントの変更」をご参照ください。

手順 2: LowNodeLoad プラグインの有効化

1. 以下の内容で koord-descheduler-config.yaml ファイルを作成します。この ConfigMap により、LowNodeLoad デスケジューリングプラグインが有効化されます。

   # 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 秒ごとに実行されます。
                                   # detectorCacheTimeout（デフォルト: 5 分）を超えてはいけません。
       dryRun: false               # 読み取り専用モード（エビクションなし）で実行する場合は true に設定します。
       # システム構成の終了。
   
       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
           args:
             apiVersion: descheduler/v1alpha2
             kind: LowNodeLoadArgs
   
             # 全リソースの使用量が lowThresholds を下回っている場合、ノードはアイドルと見なされます。
             lowThresholds:
               cpu: 20    # CPU 使用率 20%
               memory: 30 # メモリ使用率 30%
   
             # いずれかのリソースの使用量が highThresholds を超えている場合、ノードはホットスポットと見なされます。
             highThresholds:
               cpu: 50    # CPU 使用率 50%
               memory: 60 # メモリ使用率 60%
   
             # デスケジューリングの対象を特定の名前空間に限定します。
             # include と exclude は相互排他です。どちらか一方のみ構成してください。
             evictableNamespaces:
               include:
                 - default
               # exclude:
               #   - "kube-system"
               #   - "koordinator-system"

2. この ConfigMap をクラスターに適用します。

   kubectl apply -f koord-descheduler-config.yaml

3. 新しい構成を読み込むために、Koordinator Descheduler を再起動します。

   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 0
   kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 1

手順 3（任意）: 負荷感知スケジューリングの有効化

最適な負荷分散を実現するため、エビクション後に ACK Scheduler が Pod をホットスポットノードに配置しないよう、負荷感知スケジューリングを有効化します。詳細については、「手順 1: 負荷感知スケジューリングの有効化」をご参照ください。

負荷感知スケジューリングポリシーの loadAwareThreshold を、highThresholds と同じ値に設定します。値が異なる場合、エビクションされた Pod がホットスポットノードに再スケジュールされる可能性があります。特に、利用可能なノード数が少なく、類似した使用率レベルのノードが複数ある場合に顕著です。

手順 4: デスケジューリングの検証

この例では、各ノードが 104 コアおよび 396 GiB のメモリを持つ 3 ノードクラスターを使用します。

1. 以下の内容で stress-demo.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. ストレステストワークロードをデプロイします。

   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>

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 の CPU 使用率は 63% であり、設定済みのホットスポットしきい値 50% を超えています。ノード cn-beijing.10.XX.XX.215 の CPU 使用率は 17% であり、アイドルしきい値 20% を下回っています。

5. 手順 2: LowNodeLoad プラグインの有効化で説明されている通り、LowNodeLoad プラグインを有効化します。

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

   デフォルトでは、ノードがホットスポットとして分類されるには、highThresholds を連続して 5 回超える必要があります。デフォルトの 120 秒間隔では、約 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-****   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-****   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 がエビクションされ、cn-beijing.10.XX.XX.215 へ移行されました。

詳細設定

すべての Koordinator Descheduler パラメーターは、手順 2 で作成した ConfigMap で設定されます。以下に、負荷感知型ホットスポットデスケジューリングの完全な詳細設定を示します。

# koord-descheduler-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: koord-descheduler-config
  namespace: kube-system
data:
  koord-descheduler-config: |
    # システム構成。このセクションは変更しないでください。
    apiVersion: descheduler/v1alpha2
    kind: DeschedulerConfiguration
    leaderElection:
      resourceLock: leases
      resourceName: koord-descheduler
      resourceNamespace: kube-system
    deschedulingInterval: 120s  # 実行間隔。detectorCacheTimeout を超えてはいけません。
    dryRun: false               # 読み取り専用モード（エビクションなし）で実行する場合は true に設定します。
    # システム構成の終了。

    profiles:
    - name: koord-descheduler
      plugins:
        deschedule:
          disabled:
            - name: "*"  # すべてのプラグインはデフォルトで無効化されます（参考用に表示）。
        balance:
          enabled:
            - name: LowNodeLoad
        evict:
          disabled:
            - name: "*"  # すべてのプラグインはデフォルトで無効化されます（参考用に表示）。
          enabled:
            - name: MigrationController

      pluginConfig:
      - name: MigrationController
        args:
          apiVersion: descheduler/v1alpha2
          kind: MigrationControllerArgs
          defaultJobMode: EvictDirectly
          maxMigratingPerNode: 1       # ノードごとの同時移行 Pod 数の上限。0 の場合、制限なし。
          maxMigratingPerNamespace: 1  # 名前空間ごとの同時移行 Pod 数の上限。
          maxMigratingPerWorkload: 1   # ワークロード（例: Deployment）ごとの同時移行 Pod 数の上限。
          maxUnavailablePerWorkload: 2 # 移行中のワークロードごとの最大利用不可レプリカ数。
          evictLocalStoragePods: false # HostPath または emptyDir ボリュームを使用する Pod をエビクションするかどうか。
          objectLimiters:
            workload:               # 5 分間でワークロードあたり最大 1 レプリカを移行。
              duration: 5m
              maxMigrating: 1

      - name: LowNodeLoad
        args:
          apiVersion: descheduler/v1alpha2
          kind: LowNodeLoadArgs

          lowThresholds:
            cpu: 20
            memory: 30
          highThresholds:
            cpu: 50
            memory: 60

          anomalyCondition:
            consecutiveAbnormalities: 5  # ノードがホットスポットとして分類される前に、
                                          # highThresholds を連続して超える必要があるチェック回数。
                                          # エビクション後にカウンターはリセットされます。

          detectorCacheTimeout: "5m"  # ホットスポットチェックのキャッシュ期間。
                                      # deschedulingInterval 以上である必要があります。

          evictableNamespaces:
            include:
              - default
            # exclude:
            #   - "kube-system"
            #   - "koordinator-system"

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

          podSelectors:  # 指定された Pod のみを処理します。
          - name: lsPods
            selector:
              matchLabels:
                koordinator.sh/qosClass: "LS"

よくある質問

次のステップ

• 負荷感知 Pod スケジューリングの使用

• ack-koordinator コンポーネントのインストールおよび管理