博士

ロボ子、大変なのじゃ！KubernetesでCPU制限が4096mのPodが、systemd cgroupドライバ環境下で、たまに作成に失敗するらしいぞ。

ロボ子

それは困りましたね、博士。原因は何なのでしょうか？

博士

どうやらcontainerdとruncで、4096mをマイクロ秒に変換する時の計算結果が違うみたいなんじゃ。containerdが409600と410000のどっちかを出すらしい。

ロボ子

runcは常に410000を算出するのですね。containerdが409600を算出した場合、何が問題になるのでしょうか？

博士

そこがミソじゃ！containerdが409600を出すと、子cgroupのクォータ(410000)が親cgroupのクォータ(409600)を超えてしまうんじゃ。すると、Linuxカーネルが子cgroupの作成を拒否するらしい。

ロボ子

なるほど、それでPodの作成が失敗するのですね。Podのスケジュールが非決定的になるというのは、どういうことでしょうか？

博士

Podがどのノードで起動するか分からなくなるってことじゃな。CPU制限が4096mのPodを確実にデプロイできなくなってしまう。

ロボ子

一度409600でスタックしたノードは、そのPodに対して永続的に破損する、というのも気になります。

博士

そうじゃな。そのノードは、もう二度と4096mのPodを受け付けなくなる可能性があるってことじゃ。厄介じゃな。

ロボ子

containerdとruncのバージョンは、それぞれ1.7.27と1.3.2とのことです。Kubernetesのバージョンは1.30.14-eks-113cf36 (Amazon EKS)ですね。

博士

ふむふむ。Cgroupはv1で、ドライバはsystemdか。この環境で起きやすい問題なのかもしれないのじゃ。

ロボ子

再現手順としては、CPU制限4096mのPodを複数のノードにデプロイして、成功/失敗を観察するのですね。

博士

そうじゃ。失敗したPodのノードで、親cgroupのcpu.cfs_quota_usが409600になっているか確認するのも大事じゃぞ。

ロボ子

containerdとruncは、CPUクォータの計算において一貫した決定的なロジックを使用する必要がある、というのが期待される動作ですね。

博士

まさにそうじゃ！4096mなら、409600か410000のどっちかに統一してほしいのじゃ！

ロボ子

根本的な問題は、containerdとruncの間で、CPUクォータ計算ロジックに一貫性がないこと、ですね。

博士

まったくじゃ。早く修正してほしいものじゃ。しかし、4096mって、なんだか微妙な数字じゃな。4096と言えば、昔のPCのメモリを思い出すのじゃ。

ロボ子

博士、それは少し古いですね。今のPCのメモリはもっと多いですよ。

博士

むむ、ロボ子にまでバカにされるとは…。まあ、いいのじゃ。最後に一つ、ロボ子にクイズじゃ！4096mのPodが失敗する確率は、4096の何乗じゃ？

ロボ子

博士、それは確率の問題ではなく、ソフトウェアのバグの問題です！