Kubernetes Meetup Tokyo #45 での資料です https://k8sjp.connpass.com/event/223232/
kube-scheduler-simulatorを用いたSchedulerのシミュレーションとその仕組み Kensei Nakada @sanposhiho 1
View Slide
自己紹介 中田 健誠 / Kyoto Uni (4th year) 普段はバックエンドエンジニアをしてます Twitter: @sanpo_shiho GitHub: @sanposhiho member of Kubernetes/Kubernetes SIGs
もくじ 1. Kubernetes schedulerの概要 2. Kubernetes scheduler simulatorについて 3. Kubernetes scheduler simulatorの仕組みについて 3
Kubernetes schedulerについて 4
Kubernetes scheduler PodをどのNodeに割り当てるかを決定するコンポーネント 様々なリソースの状況からPodに最適なNodeを決定する 5
Scheduling Framework 公式Doc: 「Scheduling Framework | Kubernetes」より引用 6
Scheduling Framework 7## Scheduling Cycle PodをどのNodeで実行するかを決定する ## Binding Cycle Scheduling Cycle での決定を実際にクラスターに適応する
Scheduling Framework 公式Doc: 「Scheduling Framework | Kubernetes」より引用 8
Scheduling Framework Scheduling Framework (の Scheduling Cycle) のうち、 ● Filter (+ PreFilter) ● Score (+ PreScore) ● Normalized Score の結果が主にNodeの決定に影響している (+ Plugin Weight) ※ Extenderについては今回は割愛して説明します。 (scheduler simulatorでもExtenderには現状対応していません。) 9
10
Scheduling Framework Filter Podを実行できない(したくない)Nodeを候補から除外する 例えば… ・リソース不足でPodが実行できないNode ・nodeSelectorの条件に一致しないNode を除外する 11
12× × 何かしらの観点でNodeをフィルタリングする
13× × 何かしらの観点でNodeをフィルタリングする × × × × もしこの段階で候補のNodeが全滅した場合 → Preemptionする → 諦める (Unscheduled)
Preemption Podは priority（優先度）を持つことができます。 優先度は他のPodに対する相対的なPodの重要度を示します。 もしPodをスケジューリングできないときには、スケジューラーはそのPodをスケジューリングできるようにするため、優先度の低いPodをプリエンプトする（追い出す）ことを試みます。 14公式Doc: 「Pod Priority and Preemption | Kubernetes」より引用
15× × 何かしらの観点でNodeをフィルタリングする
Scheduling Framework Score 残った候補のNodeをスコアリングする。 例えば… ・全体のNodeのリソースの使用量のバランスがちょうど良くなるNodeを優先 ・Podを実行するコンテナイメージをすでに持っているNodeを優先 16
Scheduling Framework Normalize Score 全てのScoreの結果を踏まえてScoreを修正する 17
18何かしらの観点でNodeをスコアリングする
Scheduling Framework Plugin Weight Plugin ごとにScoreの重み付けをできる。 (そのプラグインのスコア) × Plugin Weight 19
20Score B プラグインのWeightが1 → 10 → 50 Score A プラグインのWeightが10 → 300 → 500
21→ 10 → 50 Node1 が最終的に選ばれる → 300 → 500 350 510
仕組みざっくりまとめ Scheduler は Scheduling Framework の流れに沿って動作 ● Filter で実行できない/したくないNodeを弾き、 ● Score, Normalized Score でNodeをスコアリングし、 ● 最後にPlugin Weightを加味して、 ● どのNodeでPodを実行するか決定する 22
Scheduler Configuration 実行する Plugin と Plugin Weightを変更できる (詳しくは公式Doc) 23
[宣伝] 詳しい話は CloudNative Days で 24
web-based Kubernetes scheduler simulator 25
Kubernetes scheduler simulator Web 上から Scheduler の動作をシミュレートすることができるWebApp。 ↓ Kubernetes SIGs のOrg元で公開 26
Kubernetes scheduler simulator ● フロントエンド + バックエンド + etcd を立ち上げるだけ ○ 内部的に Kubernetes のクラスターを立ち上げているわけではない ○ docker image をk8s.gcr.ioから公開予定 27
Background ● Scheduler がその Node を選んだ理由は簡単に見ることができない ○ ログレベルをあげる必要がある (v=10) ○ ログを確認するには強い権限が必要 ○ ログだと見にくい (主観) ● Scheduler の検証には実際のクラスターを立ち上げる必要がある ○ そのクラスター上で特定のリソースの状況を作るのもめんどくさい 28
29
特徴 ● Web 上からリソースを作成し、クラスターの特定の状態を再現できる 通常の Kubernetes と同様のyamlを使用する
スケジューリングに影響し得る リソースの作成に対応
Pod を作成するとどのNodeに配置されたかみることができる
特徴 ● プラグインごとの結果を全て可視化 ( 次スライド )
どのプラグインがどのNodeに対してどのような判断を下したかを表で確認できる
特徴 ● Scheduler の設定を Web 上から変更することができる 35
こういうことに使えるよ ● Scheduler 自体や Scheduler のプラグインごとの動作の検証 ● Scheduler の動作原理の学習 に使用することができる 36
展望 37
展望 38
展望 39
Kubernetes scheduler simulator の仕組み 40
Kubernetes scheduler simulator の仕組み どうやってクラスターを立ち上げずにシミュレートしているの？ 41
Kubernetes scheduler simulator の仕組み Scheduler に必要なコンポーネントのみを実行 (scheduler_perfの仕組みを参考にしている) scheduler_perfについて詳しくは こちらのスライドを参照 → https://speakerdeck.com/sanposhiho/kuberneteshaschedulerfalsepahuomansuwodofalseyouniji-ce-siteiruka 42
Simulator に必要なコンポーネント ● kube-apiserver (+ etcd) ● scheduler ● pv controller 43
Kubernetes scheduler simulator の機能 ● 各リソースの作成/変更/更新/削除 ● schedulerの設定の変更 ● プラグインごとのスケジューリング結果の収集/閲覧 44
Scheduler の設定変更 1. 現在動いているSchedulerを停止させる 2. ユーザーがリクエストしたKubeSchedulerConfigurationを元にSimulator向けの設定を生成 3. Schedulerを2の設定で起動する 45
Scheduler の設定変更 1. 現在動いているSchedulerを停止させる 2. ユーザーがリクエストしたKubeSchedulerConfigurationを元にSimulator向けの設定を生成 ← ？ 3. Schedulerを2の設定で起動する 46
プラグインの結果の収集 プラグイン = interfaceを満たすことで実装できる ←プラグインのFilterメソッドを実行 ↓↑結果の記録 47
プラグインの結果の収集 ● どのプラグインが ● どのNodeに対して ● どのような結果を出したのか を全て収集する ←プラグインのFilterメソッドを実行 ↓↑結果の記録 48
プラグインの結果の収集 結果を記録できるようにした新たなプラグインを動的に生成し、 デフォルトのプラグインの代わりに使用している 49
プラグインの結果の収集 結果を記録できるようにした新たなプラグインを動的に生成し、 デフォルトのプラグインの代わりに使用している 例えばFilterだとこんな感じ↓(/scheduler/plugin/plugins.go#L292) ←元のFilterプラグインのFilterメソッドを実行 結果の記録 50
プラグインの結果の収集 各プラグインは同一の resultstore を持っており、そこに結果が貯められていく 51
プラグインの結果の収集 各プラグインは同一の resultstore を持っており、そこに結果が貯められていく ↓ Schedulingの終了時に全ての結果をまとめたものがPodのAnnotationに反映される 52
プラグインの結果の収集 各プラグインは同一の resultstore を持っており、そこに結果が貯められていく ↓ Schedulingの終了時に全ての結果をまとめたものがPodのAnnotationに反映される ↓ フロントエンドがPodのAnnotationから表にして表示 53
プラグインの結果の収集まとめ 1. スケジュールの際に Filter メソッドが呼び出される 2. Filter メソッド内で元のプラグインの Filter メソッドを呼び出して結果を取得 3. 取得した結果を resultstore に記録 4. (スケジュールが進む) 5. スケジュールの終了時にresultstore が結果を Pod の annotation に記録 ↓↑結果の記録 54
まとめ ● Scheduler では内部で様々なPluginが動作している ● Kubernetes scheduler simulatorでは、Pluginごとの動作を検証しつつ、Schedulerをシミュレートできる ● 内部的にはSchedulerに必要なコンポーネントのみを立ち上げ、Pluginを動的に入れ替えることでPluginの結果の取得を可能にしている ● feature request/bug報告などお待ちしています 55
sanposhiho
reverentgeek
frogandcode
malarkey
iamctodd
sugarenia
holman
keavy
hursman
michaelherold
andyhume
ddemaree
bermonpainter