Kubernetes 1.20: SIG Scheduling の変更内容

はじめに

本ドキュメントでは、Kubernetes v1.20.0のCHANGELOGをベースにSIG Schedulingに関する機能について紹介します。

v1.20.0での変更はあまり多く有りません。主な変更をまとめると次のとおりです。

• Default Pod Topology Spread を betaに昇格
• 大きめ(主観です)のBugFixが含まれており、すべてv1.18.x, v1.19.xにbackportされているのでBug or Regressionのsectionは確認すると良さそうです。

下記 がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。

What's New (新情報)

Pod resource metrics

オンデマンドのメトリクスが /metrics/resources から利用できるようになりました。この機能を有効にすると実行中の Pod のリソースリクエストが取得できます。

Kubernetes 1.20: Metrics Changes と SIG Instrumentation の変更内容 で詳細に解説されているので参照してください。 簡単に解説すると、次のとおりです。

• Podは複数のContainer、複数にinitContainerから成るため、Pod全体としてのリソース要求量のメトリクスはこれまで出力されていませんでした。
• kube-state-metricsではコンテナ毎のリソース要求量のメトリクスを出力しているため、それらのメトリクスを使って計算することは可能でしたが、クエリが複雑になってしまう & 計算オーバーヘッドも大きいという課題がありました
  • しかも、正確に計算しようとすると、specで指定されているPod Overhead(Runtime ClassのOverhead)やEphemeral Volume, Hugepages等の要求量等も加味しなくてはいけません。
  • また、自分自信で記述したクエリ結果がschedulerが使っている値と一致している保証は自分で確保しなければならないため正確なキャパシティプランニングが困難な状態でした¹。
• このエンドポイントは、schedulerが算出したPodとしての要求量(requests/limits)を返してくれるため、メトリクス計算のオーバーヘッドを軽減でき、かつ信頼できるメトリクスを使えるようになります。
• 現時点ではfeature stateはalphaです。

Urgent Upgrade Notes（必ず一読してからアップグレードしなければならない事項）

ありません。

Deprecation (非推奨)

ありません。

API Change （API の変更）

• PodTopologySpread pluginで、明示的にk8sによるデフォルト制約 or ユーザ定義のデフォルト制約を指定するdefaultingTypeパラメータが導入されました。(#95048, @alculquicondor) [SIG Scheduling]
  • この変更は Default Pod Topology Spread を betaに昇格させる作業の一貫です。 betaに昇格させるとデフォルトでこの機能がenabledになるので、scheduling profileを使ったCluster-levelのdefault spread constraintの指定において、defaultingType: "List|System" プロパティを導入することで、空plugin設定の意図を明確に指定できるようになりました。互換性のためデフォルト値は"List"です。

Feature （機能）

• DefaultPodTopologySpread feature gateがBeta になりました。このfeature gateはデフォルトでenabledになります。(#95631, @alculquicondor) [SIG Scheduling and Testing]
  • Betaに昇格したので、scheduling profileを使ったCluster-levelのdefault spread constraintの指定の利用に際してfeature gateを明示的に設定する必要がなくなりました。
  • 逆に言うと、.spec.topologySpreadConstraintsを持たないPod²は自動でdefaultのtopology spread constraintでspreadされるようになります。都合が悪い場合はfeature gateをdisableするか、空のconstraintsを設定しましょう。
• デフォルトscheduler pluginの順序が変更され、 taintやnode affinityが使われている場合のschedule/preemption latencyが改善されます。(#95539, @soulxu) [SIG Scheduling]
• resourceVersion が同一のPodのUpdateイベントを無視するようになりました。(#96071, @Huang-Wei) [SIG Scheduling]
• Scheduling Framework: PostFilterextention pointで利用可能なPreemptionHandleでRun[Pre]ScorePlugins関数が公開されるようになりました。(#93534, @everpeace) [SIG Scheduling and Testing]
  • 1.19からScheduling FrameworkにおいてPostFilterというextention pointが導入されました。このextention pointは主にPreemptionロジックをカスタムするための導入です。Preemptionは高優先度のPod(Preemptorと呼ばれます)をスケジュールするために、いくつかの低優先度のPod(Victimと呼ばれます)を選出し停止する、という処理を行います。その際に、scheduling profileで指定された Filter/Score 関数³を呼び出したい場合があります。

    • Filter: Vicitmを選出するために、Victim候補を停止した後の仮想的なNodeに対してPreemptorがFitするかどうか？を判別するため

    • Score: 複数のNodeでVictim候補が選ばれた際に、どのNodeを最終的なVictimとして選出すべきか？つまりPreemptorをどのVictim Nodeにスケジュールすべきか？を評価するため

      です。1.19ではPreemptionHandle経由で公開されたいたのはFilter関数のみで、Score関数は公開されていませんでした。このため、Preemptor Podがvictim候補ノードを選ぶ際に設定されているscheduling profileと整合性の取れたNodeを選ぶことが困難でした⁴。この変更はPreemptionHandleでScore関数を公開する変更です。この変更によって、ユーザの定義したscheduling profileとより整合性の取れたカスタムPostFilterPluginの実装が可能になります。

• DefaultPodTopologySpreadがenabledの場合、SelectorSpreadPriority pluginはPodTopologySpreadpluginに変換されるようになります。(#95448, @alculquicondor) [SIG Scheduling]
  • これもDefault Pod Topology Spread を betaに昇格させる作業の一貫です。 kube-schedulerの設定方法は現在Scheduler ConfigurationとScheduling Policies(現在legacy扱い)を使う方法ありますが、後者で SelectorSreadPolicyを設定した時の挙動の変更です。

Failing Test (失敗しているテスト)

• "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" というConformance Testのテストケースで、テストに加えて各 hostPort への接続性の検証も行うようにしました。(#96627, @aojea) [SIG Scheduling and Testing]
  • このPRで追加されたテスト時におけるhostPortへの接続性確認ですが、hostNetwork: trueがサポートされていないWindowsでもテストが動くようになっていたようです。もともとサポートのない機能をテストしようとしてテストが落ちしまっているだけですので動作に影響は無いと思います。ちなみにですが、#97003で修正が行われています。

Bug or Regression （バグまたはリグレッション）

backportされていないバージョンを利用している方はご注意ください⚠️

• LocalStorageCapacityIsolation feature gateがdisabledな際にschedulerがそれを考慮しない問題を修正しました。(#96092, @Huang-Wei) [SIG Scheduling]
  • LocalStorageCapacityIsolation feature gateはデフォルトでenabledで、disabledにするケースは少ないと思われますが、disabledな場合、Podのephemeral volumeはschedulingにおいては無視されるべきなのですが、考慮してしまっていたというバグです。この修正はv1.19.4, v1.18.11にもbackportされています。
• (legacy) scheduler policyを利用した場合に、DefaultPreemption Pluginがdisabledになってしまう問題を修正しました。(#96439, @Huang-Wei) [SIG Scheduling and Testing]
  • Scheduling Policies(現在legacy扱い)を使ってkube-schedulerを設定すると、Preemptionが全く無効になってしまうバグの修正です。この修正はv1.19.5にもbackportされています。
• Podよりも前にそのNodeが削除された時、scheduler内部のcache snapshotが不整合になってしまう問題を修正しました。(#95130, @alculquicondor) [SIG Scheduling]
  • この修正はv1.19.3, v1.18.10にもbackportされています。

Other (その他の修正)

• Scheduler metricsエンドポイントへのリクエストが認証できない場合のメッセージを修正しました。(#94035, @zhouya0) [SIG Scheduling]
  • 内部実装でlegacyschemaを利用し続けたいたのが原因で、認証エラーの際に、認証エラーとは無関係のエラーがレスポンスされていたのですが、この修正で正しい認証エラーメッセージがレスポンスされるようになりました。
• kube-schedulerスタート時に処理されたcomponent configがログとして出力されるようになりました。(#96426, @damemi) [SIG Scheduling]
  • 便利ですね！
• Scheduler framework interfaceがpkg/scheduler/framework/v1alphaからpkg/scheduler/frameworkに移動しました。 (#95069, @farah) [SIG Scheduling, Storage and Testing]

おまけ

Scheduling Framework登場以降、かなり柔軟にカスタムスケジューラがkubernetesをforkせずに開発ができるようになってきており、kubernetes-sigs/scheduler-pluginsにいくつかPlugin拡張が公開されています。ぜひ見てみると良いと思います！

1. Nodeの空き容量メトリクスも出してほしいですね。 ↩

2. 正確には同一の service, replication controller, replica set or stateful set配下のPodに限られます ↩

3. 一般には複数のPluginが合成された関数になります ↩

4. kube-schedulerにおけるDefaultPreemption PluginはprofileのScore関数を考慮せず、VictimのPDB違反数、最大優先度の値、優先度の和、といった指標でVictim Nodeを一つにしぼっています、v1.19においては、default preemptionロジックのplugin化にフォーカスされたため、Score関数の公開は行われなかったという背景があります。ここからも分かる通り、default preemptionは、カスタムScore Pluginを利用して、できるだけPodを効果的にPackingしたいと言うような場合に不都合が発生する場合があります。 ↩