Pod Topology Spreadの超最前線 MinDomains、NodeInclusionPoliciesについて

Kubernetes Meetup Tokyo #48
https://k8sjp.connpass.com/event/237734/

Transcript

1. Pod Topology Spreadの超最前線 
 MinDomains(仮)、NodeInclusionPolicies(仮)について
 Kensei Nakada @sanposhiho
 1
2. 自己紹介
 中田 健誠 / Kyoto Uni (4th year)
 
 趣味でKubernetes(kube-scheduler)や
 周辺エコシステムにcontributeしています。
 
 Twitter: さんぽし (@sanpo_shiho)
 GitHub: @sanposhiho
 member of Kubernetes / Kubernetes SIGs

3. 今日話すこと
 Kubernetesのv1.24でPod Topology Spreadに新たに二つのAPIが追加されます。
 今日はそれぞれのAPIの提案内容と、現状のPod Topology Spreadにおける課題点/問 題点や関連する細かい仕様を紹介します。
 
 「v1.24だったらまだ先だしキャッチアップはまだ大丈夫だね〜」と思っているそこのあな た、
 Pod Topology Spreadで痛い目を見る可能性がありますよ 👀👀

4. 注意点
 今日話すMinDomainsとNodeInclusionPoliciesに関しては、
 現時点(2022/02/21)で、KEPがImplementableになり、alphaとしてv1.24で公開される予定 となっているものです。
 
 しかし、予定に狂いが生じたり、現在の提案に変更が加わる可能性があります。
 実際にリリースされた時には、この資料ではなく、公式のドキュメントを参考にして下さ い。

5. もくじ
 1. Pod Topology Spreadってなんだっけ?
 2. 現在のPod Topology Spreadの仕様における問題点/課題点 (1)
 3. NodeInclusionPoliciesについて
 4. 現在のPod Topology Spreadの仕様における問題点/課題点 (2)
 5. MinDomainsについて

6. Pod Topology Spreadってなんだっけ?
 6
7. Pod Topology Spreadってなんだっけ?
 ゾーンやノードなどの任意のドメイン間でPodをどのように分散させるかを
 制御できる機能。
 
 Kubernetes v1.19で追加された比較的新しい機能です。

8. Pod Topology Spreadってなんだっけ?
 
 pod.spec.topologySpreadConstraintsを通して設定する。
 (KubeSchedulerConfigurationにてデフォルト値を設定することも可能 (beta))
 公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用

9. topologyKey
 Nodeのラベルのkeyを示している、
 特定のラベルの値が同じNodeたちが一つのドメインとして扱われる。
 

10. topologyKey
 well-known labelと呼ばれるものがあり、それが使用されてることが多い (多分)
 例:
 kubernetes.io/hostname: 　　 Nodeの名前を示すラベル
 
 
 topology.kubernetes.io/zone: どのzoneに存在するかを示すラベル

11. topologyKey
 well-known labelと呼ばれるものがあり、それが使用されてることが多い (多分)
 例:
 kubernetes.io/hostname: 　　 Nodeの名前を示すラベル
 → 一つのNode = 一つのドメイン　になる
 
 topology.kubernetes.io/zone: どのzoneに存在するかを示すラベル
 → 一つのZoneに存在する全てのNode = 一つのドメイン　になる

12. labelSelector
 そのConstraintで対象とするPodを見つけるためのlabelSelector。
 
 labelSelectorと一致するPodはPod Topology Spreadの内部実装では
 ”matching Pod”と呼ばれることがある。
 
 つまり:
 “matching Pod” = labelSelectorに一致するPodで、すなわちそのConstraintで対象とな るPod

13. whenUnsatisfiable
 DoNotSchedule と ScheduleAnyway のどちらかの値を取る。
 
 DoNotSchedule: 制約を満たせないNodeには絶対にPodをスケジュールしない
 ScheduleAnyway: 制約を満たせないNodeにはPodをスケジュールしないように頑張る。 (= 制約を満たせないNodeにPodがスケジュールされることもある) 
 
 (Scheduling Framework的には、FilterするかScoreするかという違いです。)

14. maxSkew
 ドメイン間のmatching Podの偏りをどれだけ許容するかを示す。
 
 skew = 
 (最もmatching Podが多く存在しているドメインにおけるPodの総数)
 - (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
 

15. maxSkew
 ドメイン間のmatching Podの偏りをどれだけ許容するかを示す。
 
 skew = 
 (最もmatching Podが多く存在しているドメインにおけるPodの総数)
 - (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
 
 最もmatching Podが少なく存在しているドメインにおけるPodの総数のことを、内部実装 的にはglobal minimumと呼んでいる。

16. maxSkew
 maxSkewが1で、whenUnsatisfiableはDoNotScheduleとする。
 (青色で示されているPodはmatching Pod。)
 公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用

17. maxSkew
 新しいmatching Pod(mypod)を作ったとする
 
 もし、zoneAにPodがスケジュールされると、
 zoneAのmatching Podの数: 3
 zoneBのmatching Podの数: 1
 になる。Podの数の差は 3-1 > maxSkew(= 1) になってしまう。
 これはmaxSkewの制約に反するのでmypodは必ずzoneBのどちらかに行く

18. maxSkew
 zoneBのどちらかに
 スケジュールされれば、
 
 zoneAのmatching Podの数: 2
 zoneBのmatching Podの数: 2
 になる。
 2-2 < maxSkew(= 1) なのでOK
 ↑OR↓ になる
 公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用

19. 現在のPod Topology Spreadの仕様における
 問題点/課題点 (1)
 19
20. Skew計算時に対象にするNodeについて
 nodeAffinity/nodeSelectorはSkewの計算時に考慮される。
 
 例:
 PodがnodeAffnityで絶対にNode4にスケジュールされないようになっている場合
 ↓
 Node4がドメインの中に入っていたとしても、Skewの計算から弾かれる

21. Skew計算時に対象にするNodeについて
 nodeAffinityでNode4が弾かれる場合、Skewの計算に入れてしまうと…?
 
 → matching Podの数が増えてもNode4のmatching Pod数は絶対に0(最小値)
 → topologyKey: kubernetes.io/hostname で DoNotSchedule を使用している場合、 matching Podの数が増えていくと、maxSkewに反するようになり、どのNodeにもスケ ジュールできなくなる。
 

22. Skew計算時に対象にするNodeについて
 スケジュールできなくなる例: 右下の図だと、
 - nodeAffinityでNode4が弾かれる
 - topologyKey: kubernetes.io/hostname 
 - DoNotSchedule
 - maxSkew: 1
 の場合どこにも行けなくなる。
 公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用

23. Skew計算時に対象にするNodeについて
 しかし、TaintsとTolerationsは現状考慮されない。
 一応ドキュメントの一番下にちっちゃく一行で
 「tainted Node上のPodは考慮されます」
 (= 言い換えると、普通のNodeと同じように扱う ということですね)
 って書かれている。

26. TaintsとTolerationsが考慮されないと何が起こる?
 1. Podに topologyKey: kubernetes.io/hostname と DoNotSchedule を使っている
 2. 何らかの理由(drain等)でNodeAにNoScheduleのtaintが付く。
 3. 全てのPodはNodeAからevict(退去)される。
 4. evictされたPodがreplicasetなどの影響で再度作成され、スケジュールが開始。
 5. NodeAにはmatching Podが0個存在する。これによって、(matching Podの数が十分に 多い場合) maxSkewの制約を満たすために、Pod Topology Spreadは常にNodeAにス ケジュールしようとするようになる
 6. しかし、NodeAはUnschedulable taintがついているのでスケジュールできない
 7. NodeAがクラスタから削除される/taintが外れるまでPodが起動できない(ずっと Pending)

27. NodeInclusionPoliciesについて
 27
29. NodeInclusionPolicies (KEP-3094) 
 Pod Topology SpreadのそれぞれのConstraintにおいて、
 どのNodeを対象とするのかを指定できる機能
 
 PodSpec.TopologySpreadConstraintにNodeInclusionPolicies APIが新たに追加され、
 NodeAffinityとNodeTaintをそれぞれ適応するかどうかを指定できる。

30. ↓こんな感じ

31. 先程の問題
 先程の問題はNodeInclusionPoliciesでNodeTaintをRespectに指定することで、解決でき る
 
 (後方互換性のために、提案ではNodeInclusionPoliciesのNodeTaintに関しては、デフォ ルトがIgnoreになる。)

32. 現在のPod Topology Spreadの仕様における
 問題点/課題点 (2)
 32
33. [再掲] Pod Topology Spreadってなんだっけ?
 ゾーンやノードなどの任意のドメイン間でPodをどのように分散させるかを
 制御できる機能。
 
 Kubernetes v1.19で追加された比較的新しい機能です。

34. maxSkewに関して
 Skewは存在しているドメイン間のmatching Podの数の差で計算される。
 ↓
 maxSkewはあえて抽象的に言うと
 「すでに存在しているドメインの間で、どのようにPodを拡散するか」
 を制御するAPIである。

35. maxSkewに関して
 Skewは存在しているドメイン間のmatching Podの数の差で計算される。
 ↓
 maxSkewはあえて抽象的に言うと
 「すでに存在しているドメインの間で、どのようにPodを拡散するか」
 を制御するAPIである。
 ↓
 ドメイン自体の数を制御(増やしたり減らしたり)したい場合はどうするの…?

37. MinDomains について
 37
39. MinDomains (KEP-3022)
 Pod Topology SpreadのそれぞれのConstraintにおいて、
 ドメインの最小値を指定できる機能。
 PodSpec.TopologySpreadConstraintにMinDomains APIが新たに追加される。
 
 DoNotScheduleのみで使用可能。

40. ↓こんな感じ

41. [再掲] maxSkew
 ドメイン間のmatching Podの偏りをどれだけ許容するかを示す。
 
 skew = 
 (最もmatching Podが多く存在しているドメインにおけるPodの総数)
 - (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
 
 最もmatching Podが少なく存在しているドメインにおけるPodの総数のことを、内部実装 的にはglobal minimumと呼んでいる。

42. MinDomains (KEP-3022)
 MinDomainsが指定された場合、ドメインの数が、MinDomainsよりも少ない場合に、global minimumが常に0となる。

43. 例
 topologyKey: kubernetes.io/hostname, 
 DoNotSchedule, 
 maxSkew: 1, 
 minDomains: 5
 とする。
 4つ目まではスケジュールできるが、
 5つ目のmatching Podはスケジュールに
 失敗する。
 図は公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用
 ↓

44. 例
 4つのPodが置かれた時点で、
 どのNodeに次のPodをおいても、
 ドメイン上で2つ目のPodになる。
 MinDomainsにより、
 global minimumが0になっている。
 → skew = 2 - 0 > maxSkew (=1)
 
 なので、maxSkewに反してしまう。
 
 図は公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用
 ↓

45. 具体的にどのようなことができるようになるか
 ClusterAutoscalerが使用されている場合で、複数のドメインにPodを配置したい場合、強 制的にNodeを増やすといったことができるようになります。
 例えば、
 - topologyKey: kubernetes.io/hostname 
 - DoNotSchedule
 - maxSkew: 1
 - minDomains: 5
 の時に、スケジュール可能なNodeが4つしか存在しない場合、5つ目のmatching Podの スケジュールは失敗する。こうして、matching Podのスケジュールを失敗させることで、 CAにNodeを増やさせることができる。

46. MaxDomainsはないの?
 現状はないです。
 議論のテーブルには上がりましたが、「強く必要とされるようなユースケースが思いつか んし、一旦おいとこ」となっています。

47. 何でScheduleAnywayで使えないの?
 技術的な面で言うとパフォーマンス的なところで心配があったためです。
 (現在のドメイン数を計算するのがちょっと大変で、PreScoreでその計算を挟むことに懸 念があった。)
 
 また、その技術面の懸念を押し切るほど有用なユースケースがないためでもあります。

48. まとめ
 - Pod Topology SpreadにTaintsを考慮させることが現状はできないことから、v1.24で NodeInclusionPoliciesが導入される。
 - 現時点でDoNotScheduleを使っている人は Nodeの削除時などtaintsの扱いに注意が必要 。
 - Pod Topology Spreadにドメイン自体の数を制御させることができないことから、 v1.24でMinDomainsが導入される。