はじめに
ここでは, Kubernetes 1.14 の CHANGELOG から SIG Scheduling に関係のあるものを抜粋しています.
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md
1.14 What’s New
Pod Priority と Preemption
- Pod priority と preemption により Kubernetes scheduler がより重要度の高い Pod を一番先にスケジュールするようになり, クラスタがのリソースが足りないときには重要度の低い Pod を削除することで重要度の高い Pod のためのリソースを確保するようになります. Pod の重要度は priority によって指定されます. (#73498, #73555, #74465, kubernetes/enhancements#564)
この機能は v1.10 でアルファ, v1.11 でベータの機能となっていましたが, v1.14 から安定版の機能となりました. v1.11 から既にデフォルトで有効化されています.
Known Issues
該当なし
Deprecations
- API
PriorityClass は Pod の priority (数値) とそれに付ける名前をマッピングするためのリソースで, Pod の優先度を指定する際にはこのリソースを利用します.
Removed and deprecated metrics
Deprecated metrics
-
scheduler_scheduling_latency_secondsメトリクスはscheduler_scheduling_duration_secondsにリネームされます.
Notable Features
- scheduler が自身の持つキャッシュのスナップショットを作成するためのアルゴリズムが最適化され, スケジューリングのスループットが改善しました. (#74041)
scheduler はスケジューリングサイクルごとにキャッシュのスナップショットを作成しているようで, ここに比較的大きな CPU リソースが消費されているようです. この修正ではキャッシュエントリを双方向リストで管理するようにして更新順に辿れるようにすることで, 前回のスナップショット作成以降に更新されたエントリのみを更新できるようにしたようです. ベンチマークでは 10000 Pod, 5000 Node のスケジューリングのレイテンシを 8.5ms から 6.7ms へ 20% 程度改善できたとのことです.
- アタッチ可能な Cinder ボリュームの上限をサポートしました. (#72980)
API Changes
該当なし
Detailed Bug Fixes And Changes
API Machinery
- 同じ event が複数回送られてしまわないようにすることで, watcher が時間を遡ってしまう問題が解決しました. (#73845, #73277)
- apiserver の graceful shutdown の際, プロセスが終了する前に送信データが破棄されないように修正されました. (#72970)
Apps
- Pod eviction がデフォルトで graceful な削除となるようになりました. (#72730)
Node
- 新しい Node が作成された際, Node の正しい状態を表すよう taint される前に Pod がスケジュールされてしまうことの無いよう TaintNodesByCondition admission plugin が新しく作成された Node を "not ready" となるように taint するようになります. この plugin は TaintNodesByCondition feature により有効化されます. (#73097)
Node が追加された場合などに, not ready である場合であるにも関わらず Pod がスケジューリングされてしまう問題への対処のようです.
Scheduling
-
スケジューリングキューに Pod を配置する際, 近い過去に試行した Pod については同じ優先度を持つ他の Pod の後ろに並べるようにすることで公平性が改善されました. (#73700)
-
unschedulable な Pod であっても適切な場合にはスケジュールし直すようにすることで scheduler の安定性が向上しました. (#73700, #72558, #73078)
通常は unschedulable キューに入れられた Pod は特定の event (schedulable へ変わる可能性のありそうな event) の発生を受けてリトライされますが, 特殊な環境では Pod が unschedulable キューに入る前にしかそのような event が発生しないという状況が起きうるようで, そのような場合の対策として Pod のスケジューリングを一分ごとにリトライするようになったようです.