宿題ヘルパー Kubernetes ネイティブ スケジューラ最適化の練習

スケジューリング システムの本質は、コンピューティング サービス/タスクが安定して効率的に実行できるように適切なリソースを一致させ、これに基づいてリソースの使用密度をさらに向上させることです。 CPU、メモリ、IO、差別化されたリソースデバイスなど、アプリケーションの動作に影響を与える要素は多数あります。アプリケーション操作のパフォーマンスには、一連の要因が影響します。同時に、個別および全体的なリソース要求、ハードウェア/ソフトウェア/ポリシーの制限、アフィニティ要件、データ領域、負荷間の干渉、および周期的なトラフィック シナリオ、コンピューティング集約型シナリオ、オフライン ハイブリッドなどのさまざまなアプリケーション シナリオが絡み合うことで、意思決定にも変化が生じます。

スケジューラの目標は、この機能を迅速かつ正確に実現することですが、リソースが限られているシナリオでは、これら 2 つの目標が互いに矛盾することが多く、両者の間でトレードオフを行う必要があります。

スケジューラの原理と設計

k8s デフォルト スケジューラの全体的な動作フレームワークは、次のように簡単にまとめることができます。

2つの制御ループ

1. 最初の制御ループは、インフォーマー パスと呼ばれます。その主なタスクは、一連の Informers を起動して、クラスター内の Pod、Node、Service などのスケジュール関連の API オブジェクトの変更を監視 (監視) することです。たとえば、スケジュールされる Pod が作成されると、スケジューラは Pod Informer のハンドラを介して Pod をスケジュール キューに追加します。同時に、スケジューラはスケジューラ キャッシュを更新し、このキャッシュを参照情報として使用して、スケジューリング プロセス全体のパフォーマンスを向上させる役割も担います。

2. 2 番目の制御ループは、ポッドをスケジュールするためのメイン ループで、スケジューリング パスと呼ばれます。このサイクルのワークフローは、スケジュールするポッドをスケジューリング キューから継続的に取り出し、2 段階のアルゴリズムを実行して最適なノードを選択することです。
1. クラスター内のすべてのノードの中で、ポッドを実行できるすべてのノードを選択します。このステップは述語と呼ばれます。
2. 前の手順で選択したノードの中で、一連の最適化アルゴリズムに従ってノードにスコアを付け、スコアが最も高い「最適な」ノードを選択します。このステップは「優先順位」と呼ばれます。

スケジューリングが完了すると、スケジューラはこのノードをポッドの spec.NodeName に割り当てます。このステップはバインドと呼ばれます。メイン プロセス パスで API サーバーにアクセスしてパフォーマンスに影響を与えないようにするために、スケジューラはスケジューラ キャッシュ内の関連するポッドとノードの情報のみを更新します。この楽観的な仮定に基づく API オブジェクト更新方法は、k8s では Assume と呼ばれます。その後、Api サーバーへの更新 Bind 操作を非同期的に開始するための goroutine が作成されます。この手順が失敗しても問題ありません。スケジューラ キャッシュが更新されると、すべてが正常になります。

大規模クラスタスケジューリングがもたらす問題と課題

デフォルトの k8s スケジューラ戦略は小規模クラスターでは優れたパフォーマンスを発揮しますが、ビジネス量の増加とビジネス タイプの多様化に伴い、デフォルトのスケジューリング戦略では、スケジューリング ディメンションの減少、同時実行性の欠如、パフォーマンスのボトルネック、スケジューラの複雑化など、徐々に限界が明らかになってきています。

これまでのところ、当社の現在の単一クラスターには数千のノードと 100,000 を超えるポッドがあり、GPU やオフライン ハイブリッド展開などの複雑なシナリオを含め、全体的なリソース割り当て率は 60% を超えています。このプロセスでは、多くのスケジュール上の問題が発生しました。

問題1: ピーク時のノード負荷の不均一

デフォルトのスケジューラはワークロード要求値を参照します。リクエスト値を高く設定しすぎると、リソースの無駄遣いにつながります。値が低すぎると、ピーク時に深刻な CPU 不均衡が発生する可能性があります。アフィニティ戦略を使用すると、ある程度はこれを回避できますが、多数の戦略を頻繁に入力する必要があり、メンテナンス コストが非常に高くなります。さらに、サービス要求はサービスの実際の負荷を反映できないことが多く、矛盾が生じます。この差異エラーは、ピーク時のノード負荷の不均一性に反映されます。

リアルタイム スケジューラは、ノード スコアリングに参加するために、スケジューリング中に各ノードのリアルタイム データを取得します。しかし、実際には、リアルタイム スケジューリングは多くのシナリオには適用できません。特に、規則性が明らかなビジネスでは当てはまりません。たとえば、当社のほとんどのサービスでは、夕方のピーク時のトラフィックは通常のトラフィックの数十倍になり、ピーク時とオフピーク時のリソース使用量の差は非常に大きくなります。ビジネスリリースでは、通常、オフピークリリースが選択されます。リアルタイム スケジューラを使用すると、リリースはよりバランスが取れるようになりますが、夕方のピーク時にはノード間で大きな差が生じます。多くのリアルタイム スケジューラでは、大きな差異が発生したときに再バランス戦略を使用してスケジュールを再調整することがよくあります。サービスの高可用性の観点から、ピーク時間帯にサービス ポッドを移行することは非現実的です。明らかに、リアルタイムのスケジューリングはビジネス シナリオを満たすにはほど遠いものです。

私たちの解決策: ピーク予測が設定された時点でのディスパッチ

したがって、このような状況では予測的なスケジューリングが必要になります。過去のピーク時間帯の CPU、IO、ネットワーク、ログなどのリソースの使用状況に基づいて、ノード上のサービスの最適な配置と組み合わせを回帰することで、各サービスとリソースの重み係数が得られます。加重スコアリングはリソースに基づいて拡張されます。つまり、過去のピーク データを使用して将来のピーク ノード サービスの使用状況を予測し、それによってスケジューリング ノードのスコアリング結果に介入します。

問題2: 多様なスケジュールディメンション

ビジネスが多様化するにつれて、ログなどのスケジュールディメンションをさらに追加する必要があります。コレクターは無制限の速度でログを収集することはできず、ログ収集はノードディメンションに基づいて行われるためです。ログ収集率はバランスが取れている必要があり、ノード間の差が大きくなりすぎてはなりません。一部のサービスでは CPU 使用率は平均的ですが、ログ出力は大きくなります。ただし、ログはデフォルトのスケジューラ決定の一部ではありません。したがって、ログボリュームが大きいこれらのサービスの複数のポッドが同じノード上にある場合、マシン上のログレポートが遅れる可能性があります。

当社のソリューション: 完全なスケジュール決定要因

この問題では、明らかにスケジュールの決定を完了する必要があります。予測スケジューリングのスコアリング戦略を拡張し、ログの決定要因を追加し、ログをノードのリソースとして扱い、履歴監視によって得られたサービスに対応するログの使用状況に基づいてスコアを計算しました。

問題3: 大規模なサービススケーリングによるスケジューリングの遅延

ビジネスの複雑さが増すにつれて、ピーク時にはスケジュールされたタスクが大量に発生し、弾力的なスケーリングが集中することになります。大規模なバッチ (数千の POD) を同時にスケジュールすると、スケジュールの待ち時間が増加します。どちらもスケジュール時間に敏感で、特にスケジュールされたタスクの場合、スケジュール待ち時間の増加がはっきりと感じられるでしょう。その理由は、k8s ポッド スケジューリング自体がクラスター リソースの割り当てであり、事前選択とスコアリングの段階が順番に実行されるスケジューリング プロセスに反映されるためです。その結果、クラスターの規模が一定レベルに達すると、大規模な更新によってポッドのスケジューリングに顕著な遅延が発生します。

私たちの解決策: タスクスケジューラを分割し、同時スケジューリングドメインを増やし、バッチスケジューリングを行う

スループットが低い問題を解決する最も直接的な方法は、シリアルからパラレルに変更することです。リソースのプリエンプション シナリオでは、リソース ドメインを可能な限り絞り込み、並列で実行するようにします。上記の戦略に基づいて、独立したジョブ スケジューラを分割し、ジョブ実行の基盤となるリソースとしてサーバーレスを使用しました。 K8s サーバーレスは、各 JOB POD に対して独立した POD を適用して sanbox、つまりタスク スケジューラを実行し、完全に並列化します。

比較表:
夕方のピーク時のネイティブスケジューラのノードCPU使用率

夕方のピーク時間帯における最適化されたスケジューラのノード CPU 使用率

要約する

ワークノード リソース、GPU リソース、サーバーレス リソースは、クラスターの異種リソースが属する 3 つのリソース ドメインです。これら 3 つのリソース上で実行されるサービスには当然違いがあります。これら 3 つのリソース ドメイン上のポッドのスケジュールを管理するために、forecast-scheduler、gpu-scheduler、job-schedule の 3 つのスケジューラを使用します。

予測スケジューラはほとんどのオンライン ビジネスを管理し、リソース ディメンションを拡張し、予測スコアリング戦略を追加します。

GPU スケジューラは、GPU リソース マシンの割り当てを管理し、オンライン推論とオフライン トレーニングを実行します。両者の比率は長期間にわたって変動します。ピーク時には、オフラインのトレーニング容量が削減され、オンラインの推論容量が拡張されます。ピーク時以外は、オフラインのトレーニング容量が拡張され、オンラインの推論容量が減少します。同時に、一部のオフライン画像処理タスクが処理され、GPU マシン上の比較的アイドル状態の CPU やその他のリソースが再利用されます。

ジョブ スケジューラは、スケジュールされたタスクのスケジュールを管理する役割を担います。スケジュールされたタスクの数は多く、頻繁に作成および破棄されます。リソースの使用は非常に断片化されており、効率性に対する要件が高くなります。そのため、多数のタスクに対応し、リソースの使用率を向上させるために、クラスター内の冗長なマシン リソースを圧縮するために、サーバーレス サービスにタスクをスケジュールするようにしています。

今後の進化についての議論

より細分化されたリソースドメイン分割

リソースドメインをノードレベルに分割し、ノードレベルをロックする

リソースの優先と再スケジュール

通常のシナリオでは、ポッドのスケジュールに失敗した場合、ポッドは保留状態のままになり、ポッドが更新されるか、クラスター リソースが変更されて再スケジュールされるまで待機します。ただし、k8s スケジューラには依然としてプリエンプション機能があり、スケジューリングで高優先度ポッドの正常な動作が確保できない場合に、高優先度ポッドがノード上の一部の低優先度ポッドを排除することができます。これまで、スケジューラのプリエンプション機能は使用していませんでした。上記の戦略を使用してスケジュールの精度を高めたとしても、一部のシナリオではビジネスによって生じる不均衡を回避することはできません。このような異常なシナリオでは、スケジュールを変更する機能が役立ちます。おそらく、再スケジュールは将来、異常なシナリオに対する自動修復方法になるでしょう。

通常のシナリオでは、ポッドのスケジュールに失敗した場合、ポッドは保留状態のままになり、ポッドが更新されるか、クラスター リソースが変更されて再スケジュールされるまで待機します。ただし、k8s スケジューラには依然としてプリエンプション機能があり、スケジューリングで高優先度ポッドの正常な動作が確保できない場合に、高優先度ポッドがノード上の一部の低優先度ポッドを排除することができます。これまで、スケジューラのプリエンプション機能は使用していませんでした。上記の戦略を使用してスケジュールの精度を高めたとしても、一部のシナリオではビジネスによって生じる不均衡を回避することはできません。このような異常なシナリオでは、スケジュールを変更する機能が役立ちます。おそらく、再スケジュールは将来、異常なシナリオに対する自動修復方法になるでしょう。