チェシャ猫の消滅定理

数学にプログラミング、素敵なもの何もかも。

Kubernetes 1.13: SIG Scheduling の変更内容

はじめに

本記事では、Kubernetes 1.13 の CHANGELOG からスケジューリングに関する内容をまとめました。

主な変更点

1.13 における SIG Scheduling の取り組みは主に安定性に焦点を当てており、いくつかの大きな機能の導入は次のバージョンまで延期することになりました。特記すべき変更として次に挙げる 2 点があります。

#69824: Taint based Eviction の有効化

TaintBasedEvictions がベータに移行し、デフォルトで有効になりました。この機能が有効になっている場合、Node には自動的に条件 Taint が付加され、Pod は必要であれば Toleration を使用することができます。

Taint based eviction は、Node に問題が発生した際、その内容に応じて Node Controller が以下のような Taint を自動的に付加する仕組みです。

  • node.kubernetes.io/not-ready
  • node.kubernetes.io/unreachable
  • node.kubernetes.io/out-of-disk
  • node.kubernetes.io/memory-pressure
  • node.kubernetes.io/disk-pressure
  • node.kubernetes.io/network-unavailable
  • node.kubernetes.io/unschedulable
  • node.cloudprovider.kubernetes.io/uninitialized

今まで Pod のスケジューリングには「Not Ready な Node を避ける」といったロジックが入っていました。1.13 からこの TaintBasedEvictions がデフォルトで有効になったことにより、障害時の Pod 退避は Taint による管理に統一されます。

Taint と Tolaration によるスケジューリングに統一されることで、Node 障害時の挙動をユーザがより柔軟にコントロールできるようになります。例えば Pod に tolerationSeconds を指定することで「Node に問題 X が発生した際は n 秒以内に回復しなければ移動」といった挙動の調整が可能です。

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

ちなみに、tolerationSeconds が設定されていない場合、Admission Control により not-ready と unreachable に 300 秒の tolerationSeconds が設定されます。要するに何も設定していない場合は Node の障害から最大 300 秒待って Pod が削除される、ということです。

#70298: critical-pod アノテーションが非推奨に

Pod に対するクリティカルアノテーションが非推奨になりました。アノテーションの代わりに Pod の優先度を使用すべきです。

DNS や Metrics Server といった死なれるとクラスタ全体の動作に影響するような Pod のために、従来 scheduler.alpha.kubernetes.io/critical-pod というアノテーションが用意されていましたが、今回から非推奨になりました。

代わりに、デフォルトで定義されている優先度クラス system-cluster-critical と system-node-critical を使用します。両者の定義は以下のようになっており、Node の移動が許容できるかどうかで用途が分かれています。

Name:           system-cluster-critical
Value:          2000000000
GlobalDefault:  false
Description:    Used for system critical pods that must run in the cluster, but can be moved to another node if necessary.
Annotations:    <none>
Events:         <none>
---
Name:           system-node-critical
Value:          2000001000
GlobalDefault:  false
Description:    Used for system critical pods that must not be moved from their current node.
Annotations:    <none>
Events:         <none>

ただしこれらの優先度クラスは、1.11 以降 kube-system Namespace 内でしか使えないことに注意が必要です。

また、この件とは直接関係しませんが、優先度による Preemption の動作原理については半年ほど前に書いた記事があるのでよければこちらもご笑覧ください。

ccvanishing.hateblo.jp

#70040: 要対応

1.13 では kube-scheduler の設定ファイルの apiVersion が componentconfig/v1alpha1 ではなく kubescheduler.config.k8s.io/v1alpha1 になります。

API グループ componentconfig は解体されつつあり、Scheduler 以外にも例えば kubeproxy.config.k8s.io が 1.9 から導入されています。

しかし、そもそもこの設定ファイルの書式はドキュメントに記載されていないし、サンプルファイルのようなものも提供されていません。対応する構造体が以下に定義されているので、ファイルの記載項目を確認することは一応可能です。

SIG Scheduling リリースノート

メトリクス追加を除き、内部ロジックの修正のみです。

#59529

ボリュームをスケジューリングする操作にメトリクスが追加されました。

以下のメトリクスが登録されるようになっています。

  • binder_cache_requests_total
  • scheduling_duration_seconds
  • scheduling_stage_error_total

#65350

Toleration を含む大量の Pod を処理する際のメモリ使用量とパフォーマンスが向上しました。

#69758

ゾーン内の Node がすべて削除された際、スケジューラが無限ループに陥るバグを修正しました。

#71212

Pod のバインディングでエラーが発生した際、古いキャッシュが使用されないよう削除するようにしました。

#71063

スケジューラ内部のキャッシュが不整合になった際、panic になる挙動を修正しました。

#71085

kube-scheduler のリーダ選出がデッドロックに陥った際、unhealthy を報告するようになりました。

#70898

必要のない Pod まで preemption してしまう潜在的なバグを修正しました。

まとめ

ユーザ側にとってさほど大きな変更点はありませんが、これまで Pod の優先度を導入しないまま運用していた場合、critical-pod アノテーションの件で影響を受ける可能性があります。まだ非推奨になっただけで廃止ではありませんが、早めに変更しておきましょう。

なお、このところ機能追加という意味では SIG Scheduling はやや低調で、実際マンパワーが足りていない印象がありますが、水面下では興味深い動きもいくつか見られます。

  • スケジューラに拡張点を設けてカスタマイズ可能にする Scheduling Framework
  • 複数の Pod を同時に All or Nothing でスケジューリングする coscheduling（旧称 Gang Scheduling）

あたりが目下のところ予定されている大きな機能追加ですが、それはまた別の話。