Container Service for Kubernetes:負荷対応スケジューリングの使用

前提条件

• ack-koordinator 1.1.1-ack.1以降がインストールされます。 詳細については、「ack-koordinator (FKA ack-slo-manager) 」をご参照ください。

• インストールされているACKスケジューラkube-schedulerのバージョンは、クラスターのKubernetesバージョンと一致します。 負荷認識スケジューリングを有効にするには、次のバージョンマッピングが必要です。

  Kubernetesバージョン	ACKスケジューラーバージョン
  ≥ 1.26	すべてのバージョン
  1.24	≥ 1.24.6-ack-4.0
  1.22	≥ 1.22.15-ack-4.0

課金ルール

ack-koordinatorコンポーネントをインストールして使用する場合、料金はかかりません。 ただし、次のシナリオでは料金が請求される場合があります。

• ack-koordinatorは、インストール後にワーカーノードリソースを占有する管理対象外のコンポーネントです。 コンポーネントのインストール時に、各モジュールが要求するリソースの量を指定できます。

• 既定では、ack-koordinatorは、リソースプロファイリングやきめ細かいスケジューリングなどの機能のモニタリングメトリックをPrometheusメトリックとして公開します。 ack-koordinatorのPrometheusメトリクスを有効にし、PrometheusのManaged Serviceを使用する場合、これらのメトリクスはカスタムメトリクスと見なされ、料金が課金されます。 料金は、クラスターのサイズやアプリケーションの数などの要因によって異なります。 Prometheusメトリクスを有効にする前に、Prometheusのマネージドサービスの課金概要トピックを読んで、カスタムメトリクスの無料クォータと課金ルールを確認することをお勧めします。 リソース使用量を監視および管理する方法の詳細については、「リソース使用量と請求書」をご参照ください。

制限事項

• ACK Proクラスターのみが負荷認識スケジューリングをサポートしています。 詳細については、「ACK Proクラスターの作成」をご参照ください。

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

ACKスケジューラkube-schedulerの負荷認識スケジューリング機能は、Kubernetesスケジューリングフレームワークに基づいて設計されています。 Kubernetesスケジューラは、リソース割り当てに基づいてポッドをノードにスケジュールします。 ACKスケジューラは、ノードの負荷に基づいてポッドをノードにスケジュールします。 負荷認識スケジューリングが有効になった後、システムはノードの負荷の履歴統計をレビューします。 次に、システムは、負荷分散を実装するために、負荷の低いノードにポッドをスケジュールします。 これにより、過負荷ノードによるアプリケーションまたはノードのクラッシュが防止されます。

次の図は、ポッドのスケジューリング時のKubernetesスケジューラとACKスケジューラの違いを示しています。 Requestedは、ノード上のポッドによって要求されるリソースを示し、Usageは、ノード上のポッドによって使用されているリソースを示します。 システムがノードの負荷を計算するとき、使用中のリソースのみが考慮される。 この場合、ノードBの負荷が低いため、ACKスケジューラはノードBにポッドをスケジュールする。

時間が経つにつれて、クラスタ環境、トラフィック、またはノード上のワークロードへの要求が変化し、ノード間の負荷分散が不均衡になる可能性があります。 この問題を防ぐために、ack-koordinatorは負荷認識ホットスポットのスケジューリング解除機能を提供します。 ホットスポットのスケジューリング解除と組み合わせて負荷認識スケジューリングを使用して、ノード間の最適な負荷分散を実現できます。 負荷認識ホットスポットのスケジューリング解除機能の詳細については、「負荷認識ホットスポットのスケジューリング解除」をご参照ください。

制御ポリシー機能の動作

負荷認識スケジューリングは、ack-koordinatorと組み合わせてkube-schedulerを使用することによって実装されます。 ack-koordinatorは、ノードのリソース使用率に関するメトリックの収集とレポートを担当します。 ACKスケジューラは、リソース利用に基づいてノードスコアを計算し、ノードスコアに基づいてノードをソートする役割を果たす。 ACKスケジューラは、より低い負荷を有するノードに新しいポッドを優先的にスケジューリングする。 ack-koordinatorのアーキテクチャの詳細については、「ack-koordinatorアーキテクチャ」をご参照ください。

スケジューリングポリシー

手順1: 負荷対応スケジューリングの有効化

1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、[操作] > [アドオン] を選択します。

3. On theアドオンページ, 検索久保スケジューラをクリックし、設定で、久保スケジューラカード。

4. では、Kube Schedulerパラメータダイアログボックスで、ロード対応スケジューリングの有効化次の表の説明に従ってパラメーターを設定し、OK.

   次の表に、主要なパラメーターを示します。 その他のパラメーターとパラメーターに必要なコンポーネントのバージョンの詳細については、「kube-scheduler」および「Custom parameters of kube-scheduler」をご参照ください。

   パラメーター	タイプ	説明	有効値	例
   loadAwareThreshold	値は、resourceNameフィールドとresourceWeightフィールドで構成されます。	このパラメーターには、ノードフィルタリングのしきい値を指定します。 このパラメーターは、[負荷対応スケジューリングの有効化] を選択した後に使用できます。	resourceName: 有効な値はcpuとmemoryです。 threshold: 有効な値の範囲は0から100です。 デフォルトでは、このパラメータは空のままになり、ノードフィルタリングは無効になります。	resourceName: cpu しきい値: 80
   loadAwareResourceWeight	値は、resourceNameフィールドとresourceWeightフィールドで構成されます。	このパラメーターは、ノードソートのノードスコアの計算に使用するリソースの重みを指定します。 このパラメーターは、[負荷対応スケジューリングの有効化] を選択した後に使用できます。	resourceName: resourceNameパラメーターのスキーマが検証されました。 値はcpuまたはmemoryのみです。 resourceWeight: 有効値は1から100の範囲の整数です。 デフォルト値: cpu=1、memory=1。	resourceName: cpu resourceWeight: 1
   loadAwareAggregatedUsageAggregationType	enum	このパラメーターは、統計のデータ集計のタイプを指定します。 有効な値： avg: 平均値を計算します。 p50: 統計の50% を計算します。 p90、p95、p99: 統計の90% を計算し、統計の95% を計算し、統計の99% を計算する。	avg p50 p90 p95 p99 デフォルト値: avg。	p90

   クラスターの詳細ページの左側のナビゲーションウィンドウで、[クラスター情報] をクリックします。 [基本情報] タブのクラスターのステータスが [実行中] に変わった場合、負荷認識スケジューリングが有効になります。

ステップ2: 負荷認識スケジューリングのテスト

次の例では、3つのノードを含むクラスターが使用されています。 各ノードは、4コアと16 GiBのメモリを有する。

1. stress-demo.yamlという名前のファイルを作成し、次のコードをファイルにコピーします。

   YAMLコンテンツを表示する:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: stress-demo
     namespace: default
     labels:
       app: stress-demo
   spec:
     replicas: 1
     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
   # Expected output
   deployment.apps/stress-demo created

3. 次のコマンドを実行し、ポッドのステータスが実行状態になるまで監視します。

   kubectl get pod -o wide

   期待される出力:

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

   stress-demo-7fdd89cc6b-g **** ポッドは、cn-beijing.10.XX.XX.112ノードにスケジュールされます。

   3分待って ポッドが初期化され、ノードの負荷が増加していることを確認します。

4. 次のコマンドを実行して、各ノードのロードを照会します。

   kubectl top node

   期待される出力:

   NAME                    CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.10.XX.XX.110   92m          2%     1158Mi          9%
   cn-beijing.10.XX.XX.111   77m          1%     1162Mi          9%
   cn-beijing.10.XX.XX.112   2105m        53%    3594Mi          28%

   cn-beijing.10.XX.XX.111のノードは、すべてのノードの中で最も負荷が低くなります。 cn-beijing.10.XX.XX.112のノードは、すべてのノードの中で最も負荷が高くなります。 これは、ノード間の負荷が不均衡であることを示す。

5. nginx-with-loadaware.yamlという名前のファイルを作成し、次のコードをファイルにコピーします。

   YAMLコンテンツを表示する:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-with-loadaware
     namespace: default
     labels:
       app: nginx
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 500m
             requests:
               cpu: 500m

6. 次のコマンドを実行してポッドを作成します。

   kubectl create -f nginx-with-loadaware.yaml
   # Expected output
   deployment/nginx-with-loadawre created

7. 次のコマンドを実行して、ポッドがスケジュールされているかどうかを確認します。

   kubectl get pods | grep nginx

   期待される出力:

   nginx-with-loadaware-5646666d56-2****   1/1     Running   0          18s   10.XX.XX.118   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-7****   1/1     Running   0          18s   10.XX.XX.115   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-k****   1/1     Running   0          18s   10.XX.XX.119   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-q****   1/1     Running   0          18s   10.XX.XX.113   cn-beijing.10.XX.XX.111   <none>           <none>
   nginx-with-loadaware-5646666d56-s****   1/1     Running   0          18s   10.XX.XX.120   cn-beijing.10.XX.XX.111   <none>           <none>
   nginx-with-loadaware-5646666d56-z****   1/1     Running   0          18s   10.XX.XX.116   cn-beijing.10.XX.XX.111   <none>           <none>

   上記の出力は、クラスターの負荷認識スケジューリングが有効になった後、クラスターがノードの負荷を監視し、スケジューリングポリシーを使用してポッドをcn-beijing.10.XX.XX.112ノード以外のノードにスケジュールできることを示しています。

次のステップ

負荷対応スケジューリング設定の変更

1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、[操作] > [アドオン] を選択します。

3. On theアドオンページ, 検索久保スケジューラをクリックし、設定で、久保スケジューラカード。

4. では、Kube Schedulerパラメータダイアログボックスで、負荷認識スケジューリングに関連するパラメーターを変更し、OK.

   クラスターの詳細ページの左側のナビゲーションウィンドウで、[クラスター情報] をクリックします。 [基本情報] タブのクラスターのステータスが [実行中] に変わると、負荷認識スケジューリング設定が変更されます。

負荷対応スケジューリングの無効化

[Kube Schedulerパラメーター] ダイアログボックスで、[負荷対応スケジューリングの有効化] を解除し、[OK] をクリックします。

クラスターの詳細ページの左側のナビゲーションウィンドウで、[クラスター情報] をクリックします。 [基本情報] タブのクラスターのステータスが [実行中] に変わった場合、負荷認識スケジューリングは無効になります。

よくある質問

ポッドのバッチを作成した後、負荷が最も低いノードにポッドがスケジュールされないのはなぜですか?

スケジューラがすべてのポッドを最低負荷のノードにスケジュールする場合、ノードはホットスポットノードになります。

この問題を防ぐために、ノードにリソース使用率データが報告されない新しいポッドがある場合、負荷認識スケジューリングプラグインはノードスコアを適切に調整します。

ノードの負荷に加えて、負荷認識スケジューリングの結果に影響を与える要因は何ですか?

Kubernetesスケジューラは、複数のプラグインで構成されています。 アフィニティプラグインやトポロジプラグインなどの一部のプラグインは、ノードのスコアリングとソートを担当します。 ノードは、プラグインによってまとめてソートされます。 ビジネス要件に基づいて、さまざまなプラグインによって与えられるスコアの重みを調整できます。

スケジューラーバージョンを更新した後、以前のバージョンのスケジューラープロトコルでサポートされている負荷認識スケジューリング機能は有効になっていますか。

以前のバージョンのスケジューラープロトコルの負荷認識スケジューリング機能を使用するには、ポッド構成にalibabacloud.com/loadAwareScheduleEnabled: "true" アノテーションを追加します。

次の表は、異なるプロトコルバージョンとコンポーネントバージョン間の互換性を示しています。