そのPending Pod、いつになったら動くの？ ― 再試行の仕組みから読み解く、kube-schedulerの現在地

「リソースは空いたはずなのに、まだPending？」Kubernetesを運用していると、そんな場面に遭遇することがあります。kubectl describe podでSchedulingに失敗した理由は確認しても、そのPodがその後どこで待ち、何をきっかけに再びSchedulingされるのかまで意識する機会は少ないのではないでしょうか。

本セッションでは、kube-schedulerのScheduling Queueを題材に、失敗したPodがQueueの中でどこに置かれ、どのような仕組みで再試行へ戻るのかを実装から読み解きます。同じCluster Eventでも再試行対象のPodが異なるのはなぜか。QueueingHintとbackoffの役割を掘り下げます。さらにWorkload-Aware Schedulingの実現に向け、PodGroup単位で複数Podを扱うScheduling Queueの拡張も追っていきます。

Pending Podに遭遇したとき、「なぜ失敗したか」だけでなく「何が変われば次の試行につながるのか」を切り分けられる視点を持ち帰ってもらうことを目指します。