クラウド コンピューティングとコンテナ技術の発展に伴い、ドッカーをコアとするコンテナ技術が開発者やテクノロジー企業によって急速に適用され、Kubernetes はエンタープライズ レベルとプロダクション レベルの豊富な機能を備えた事実上のコンテナ クラスタ管理システムになりました。ただし、k8s は通用性スケジューリング アルゴリズムを弱めます定制性.この記事では、スケジューリング アルゴリズムをカスタマイズする方法を調査し、オープン ソースの実装を提供します。
k8s とスケジューラのアーキテクチャ
図 1-1 は Kubernetes の全体的なアーキテクチャ図です. クラスタ ノードはMaster节点と の2 つの役割に分けられますNode节点. マスター ノードは、クラスター全体の管理センターであり、クラスター管理、コンテナー スケジューリング、状態ストレージ、およびマスター ノードで実行されるその他のコンポーネントを担当します。ノード ノードは、特定のコンテナーの実行を担当する実際の作業ノードです。
図 1-1 Kubernetes の全体的なアーキテクチャ
Kubernetes スケジューラは独立して実行されるプロセスであり、内部で実行されるプロセスは複数のモジュールに論理的に分割できます。図 1-2 に、デフォルト スケジューラに含まれる特定のモジュールを示します. 構成モジュールは、スケジューラの構成情報を読み取り、構成内容に従ってスケジューラを初期化する役割を担います。
優先度キュー モジュールは優先度ヒープ データ構造であり、優先度に従ってスケジュールされるポッドを並べ替える責任があります. 優先度が最も高いポッドが先頭にあり、スケジューラは優先度キューをポーリングします. Pod がキューにスケジュールされると、スケジューリング プロセスが実行されます[1]。
スケジューリング モジュールは
算法模块、 、Node缓存および调度扩展点の 3 つの部分で構成されます。アルゴリズム モジュールは、ノードの CPU とメモリの使用量のバランスをとる NodeResourcesBalancedAllocation アルゴリズムなど、ノードをスコアリングするための一連の基本的なアルゴリズムを提供します。アルゴリズム モジュールはスケーラブルであり、ユーザーは変更および変更が可能です。独自のスケジューリング アルゴリズムを追加します。ノード キャッシュ モジュールはクラスタ ノードの最新の状態データをキャッシュし、スケジューリング アルゴリズムにデータ サポートを提供します。スケジューリング拡張ポイントは一連の拡張ポイントで構成され、各拡張ポイントはさまざまな機能がありますが、最も重要な拡張ポイントは Filter、Score、および Bind です。これら 3 つの拡張ポイントです。最後に、バインディング モジュールは、スケジューラによって選択されたノードとポッドをバインドします。
図 1-2 Kubernetes スケジューラのアーキテクチャ
Kubernetes スケジューラ コードは、コア パーツとプラグ可能なパーツを含む、プラグ可能なプラグイン設計のアイデアを採用しています。図 1-2 の構成モジュール、優先度キュー、およびノード キャッシュはコア部分であり、アルゴリズム モジュールとスケジューリング拡張ポイントはプラグ可能な部分です。このプラグイン設計により、スケジューラーの一部の機能をプラグインを介して実装できます。これは、スケジューラーのコア コードをシンプルで保守しやすい状態に保ちながら、コードの変更や機能拡張に便利です [2 ]。
図 1-3 に、スケジューラ拡張ポイント モジュールに含まれる特定の拡張ポイントを示します。Pod のスケジューリング プロセスは调度周期とに分けられ绑定周期、スケジューリング サイクルとバインディング サイクルが一緒になって Pod のスケジューリング コンテキストを構成します。スケジューリング コンテキストは、一連の拡張ポイントで構成され、各拡張ポイントは機能の一部を担当します. 最も重要な拡張ポイントは、スケジューリング サイクルおよびバインディングにおける事前選択 (フィルター) および優先 (スコア) 拡張ポイントです。 (バインド) バインド サイクルの拡張ポイント。
事前選択拡張ポイントは、各ノードが Pod のリソース要件を満たすことができるかどうかを判断し、満たされていない場合はノードを除外する役割を果たします。優先拡張ポイント パーツは、各 Pod に対してデフォルトのスコアリング アルゴリズムを実行し、最終的なスコアが加重および集計されて、すべてのノードの最終的な総合スコアが取得されます。スケジューラは、総合スコアが最も高いノードを選択します。スケジューラーは、水塘采样算法スケジューリングの結果としてノードの 1 つをランダムに選択し、ノード上の Pod によって要求されたリソース使用量を予約して、他の Pod によって使用されないようにします。バインド サイクルでは、スケジューラーは Pod を最高スコアのノードにバインドします。このステップの本質は、Pod オブジェクト内のノード関連の情報を変更し、それをストレージ コンポーネント etcd に更新することです。
図 1-3 Kubernetes スケジューラ拡張ポイントのアーキテクチャ
カスタマイズされたアルゴリズム ソリューション
カスタム スケジューリング アルゴリズムを実装する場合は、主に次の 3 つのオプションがあります。
デフォルト スケジューラのソース コードを変更し、独自のスケジューリング アルゴリズムを追加してから、スケジューラを再コンパイルしてデプロイする.論文 kcss [3]および kubecg [4]でのスケジューラの研究は、この方式に基づいています。
独自のスケジューラーを開発し、デフォルトのスケジューラーと同時にクラスターで実行します。
Kubernetes Scheduler Extender メカニズム[5]に基づいて、カスタム アルゴリズムが拡張スケジューラに実装され、論文の動的 IO [6]でのアルゴリズムの実装はこのスキームに基づいています。
上記の 3 つのカスタム スケジューリング アルゴリズムの実装スキームの長所と短所を表 2-1 に示します。概して、
ソリューション 1 の変更は最小ですが、これを行うとオープン ソース ソフトウェアの保守性が損なわれます. Kubernetes バックボーン コードが更新されると、変更されたスケジューラはアップストリーム コードと一致する必要があり、多くの保守とテスト作業が必要になります.
解決策 2 は、独自のスケジューラーを実装し、クラスター内で複数のスケジューラーを実行することですが、複数のスケジューラー間でクラスター リソース データの同期が行われず、同時スケジューリング データの競合とデータの不整合の問題があります。
解決策 3 では、デフォルトのスケジューラが API を介してエクステンダーと対話する必要があり、新しいネットワーク リクエストにより、スケジューリング プロセス全体の時間が長くなります。
表 2-1 自社開発のスケジューリング アルゴリズム ソリューションの比較
| プラン | アドバンテージ | 欠点 |
|---|---|---|
| 解決策 1: スケジューラのソース コードを変更する | マイナーな変更 | 壊れたソース コード、保守が容易ではない |
| シナリオ 2: 複数のスケジューラーの実行 | ソースコードの変更なし | データ競合、矛盾があります |
| 解決策 3: 拡張スケジューラを開発する | ソースコードの変更なし | ネットワーク時間の消費があります |
この論文のスケジューラの実装は方式 3 を採用し、Scheduler Extender メカニズムと API 仕様に準拠する拡張スケジューラが設計および開発され、Liangと名付けられました。コード 2-1 は、拡張スケジューラの JSON 形式のポリシー構成ファイルです. ポリシー ファイルは、構成ファイル パラメーターを介して Kubernetes デフォルト スケジューラに渡されます. urlPrefix は、実行後に拡張スケジューラ Liang によって監視される API アドレスを示します. priorityVerb は、優先拡張ポイントがスケジューラーの拡張ルーティングにあることを示します。デフォルトのスケジューラーは、優先拡張ポイントでスコアリング プラグインの実行を完了すると、HTTP POST ネットワーク リクエストを Liang の API アドレスに送信し、Pod と候補ノードの情報を HTTP 本文で一緒に渡します。POST リクエストを受信した後、拡張スケジューラ Liang はスコアリング アルゴリズムに従ってノードをスコアリングし、結果をデフォルト スケジューラに返します。
{
"kind": "Policy",
"apiVersion": "v1",
"extenders": [
{
"urlPrefix": "http://localhost:8000/v1",
"prioritizeVerb": "prioritizeVerb",
"weight": 1,
"enableHttps": false,
"httpTimeout": 1000000000,
"nodeCacheCapable": true,
"ignorable": false
}
]
}コード 2-1
図 2-1 は、拡張されたデフォルト スケジューラ (kube-scheduler) の起動プロセスを示しています. 拡張スケジューラ Liang の構成情報は、kube-policy.json 構成ファイルを介してデフォルト スケジューラに伝えられます.
図 2-1 構成ファイルをデフォルトのスケジューラーに渡すことによって、拡張スケジューラーが開始されます。
拡張スケジューラ梁
拡張スケジューラ Liang は、Kubernetes のデフォルト スケジューラから独立しています. Liang のモジュール設計と組織構造は、図 3-1 に示されています。クラスタ内で Prometheus と node-exporter を実行することにより、多次元のリソース データ収集が実現されます. 拡張スケジューラ Liang は、Prometheus から多次元インジケータを取得し、スケジューリング アルゴリズムを使用して結果をデフォルトのスケジューラに返す責任があります.
図 3-1 拡張スケジューラ Liang の全体的なアーキテクチャ
APIサーバーモジュールは、拡張スケジューラーのデータ形式と送信仕様に準拠したAPIインターフェースの実装を担当し、LiangはKubernetesからのスコアリングリクエストを受け取り、リクエスト内のPodと候補ノードの情報を解析して渡します。候補を取得するための内部スケジューリング アルゴリズムへのパラメーターとして ノードのスコアリング結果は、デフォルトのスケジューラーに返されます。
スケジューラ Liang のコア モジュールを拡張するスケジューリング アルゴリズム モジュールは、カスタム スケジューリング アルゴリズムの実装を担当します。拡張スケジューラ メカニズムのおかげで、複数のカスタム スケジューリング アルゴリズムを Liang に実装できます。この論文では主に、BNP と CMDN という 2 つのスケジューリング アルゴリズムを設計および実装します。
データ キャッシュ モジュールには、次の 2 つの主な機能があります。
Prometheus の API をリクエストして、Kubernetes クラスター全体のすべてのノードのステータス データを取得します。
メモリベースのインデックス データ キャッシュ メカニズムを実装し、インデックス データを読み書きするためのインターフェイスを提供し、アルゴリズムの実行時に多次元インデックス データを取得する速度を向上させます。
Liang は Go 言語を使用して開発し、コード サイズは約 3400 行で、オープン ソースの Web サイトは Liang オープン ソース アドレス[7]です。
表 3-1 は、拡張スケジューラがキャッシング メカニズムを使用するかどうかと、デフォルト スケジューラを使用してスケジューリングの決定を行うかどうかの時間のかかる比較を示しています. スケジューリング時間は、Kubernetes スケジューラのソース コードにタイムスタンプを出力し、それぞれ 9 回実行することによって得られます。平均値を計算します。表 3-1 からわかるように、デフォルトのスケジューラはスケジューリングの決定に 1 ミリ秒未満の非常に短い時間しかかかりません。拡張スケジューラとキャッシング機構を追加した場合、平均スケジューリング決定時間は 4.439ms であり、デフォルト スケジューラよりも約 3ms 長くなります. 増加した時間は、主にデフォルト スケジューラと拡張スケジューラ間のネットワーク要求時間によるものです. Liang と Liang は、スケジューリング アルゴリズムの実行にかかる時間です。
拡張スケジューラがキャッシュ メカニズムを追加しない場合、各スケジューリング決定にかかる平均時間は 1110.439 ミリ秒であり、スケジューリングにかかる時間は 100 倍以上急速に増加します。スケジューリングの決定が行われるたびにクラスタにインデックス データ。したがって、拡張スケジューラとキャッシング メカニズムにより、Prometheus によってもたらされるネットワーク要求時間を回避し、拡張スケジューラの意思決定時間を短縮し、拡張スケジューラのパフォーマンスを向上させることができます。
表 3-1 異なるスケジューラ アーキテクチャの意思決定時間
| スケジューリング タイプ | 平均決定時間 |
|---|---|
| デフォルトのスケジューラ | 0.945ms |
| 拡張スケジューラ - キャッシュを使用 | 4.439ms |
| 拡張スケジューラ - キャッシュを使用しない | 1110.439ms |
BNP アルゴリズム
BNP アルゴリズムは Liang に実装されており、ネットワーク IO の使用を k8s スケジューリング アルゴリズムの考慮に組み込み、クラスター内のネットワーク IO の使用のバランスをとることができます。
図 3-2 は、実験におけるデフォルト スケジューリング アルゴリズムと BNP アルゴリズムにおけるクラスタ全体のネットワーク IO リソースの変化を示しています.データは、各 Pod がデプロイされると収集され、合計 9 つの Pod がデプロイされます. BNP 実験でのネットワーク IO リソースの配分は、デフォルトのスケジューリング アルゴリズムよりもバランスが取れていることがはっきりとわかります。
図 3-2 bnp アルゴリズムのネットワーク IO 使用率の変化
CMDN アルゴリズム
CMDN アルゴリズムは Liang に実装されています. その目標は, クラスター内の多次元リソース割り当てをよりバランスのとれたコンパクトにすることです. コアステップは、CPU, メモリ, ディスク IO, ネットワーク IO, ネットワークの 5 つの指標を包括的にソートすることです.カードの帯域幅 Pod をデプロイするのに最適なノード。図 3-3 は、実験での CPU 使用率の変化を比較したもので、CMDN 分散戦略の下での CPU 使用率のバランスが、デフォルトのスケジューリング アルゴリズムの場合よりもバランスが取れていることが明確にわかります。
図 3-3 cmdn アルゴリズムのバランシング戦略の下での CPU 使用率の変化
要約する
Kubernetes スケジューリング アルゴリズムの一般性は、アルゴリズムのカスタマイズを弱めます。このホワイト ペーパーでは、k8s スケジューラ アーキテクチャと拡張メカニズムを研究し、カスタマイズされた 3 つのスケジューリング アルゴリズム スキームを比較し、実装する拡張スキームを選択し扩展调度器Liang、2 つのスケジューリング アルゴリズム BNP と CMDN を Liang に実装して、カスタマイズされたアルゴリズムの能力を実証します。
拡張スキームは、カスタマイズされたスケジューリング アルゴリズムの機能を大幅に強化し、多くのカスタマイズされたシナリオのニーズを満たすことができます。同時に、カスタム スケジューリング アルゴリズムは多くの場合、より多くのデータを必要とするため、k8s クラスターにデータ取得モジュールを追加でデプロイする必要があり、運用と保守のコストが増加し、カスタマイズされたスケジューリング アルゴリズムの汎用性が低下することに注意してください。
参考文献
[1]
キューにスケジュールする Pod がある場合、スケジュール プロセスが実行されます: http://dx.doi.org/10.24138/jcomss.v16i1.1027
[2]同時に、スケジューラのコア コードをシンプルで保守しやすくします: https://v1-20.docs.kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/
[3]kcss: https://doi.org/10.1007/s11227-020-03427-3
[4]kubecg: https://doi.org/10.1002/spe.2898
[5]Kubernetes スケジューラ エクステンダー メカニズム: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md
[6]動的 IO: https://doi.org/10.1145/3407947.3407950
[7]Liang オープン ソース アドレス: https://github.com/adolphlwq/liang