Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pod Topology Spreadの超最前線 MinDomains、NodeInclus...

sanposhiho
February 22, 2022
1.4k

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

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

sanposhiho

February 22, 2022
Tweet

More Decks by sanposhiho

Transcript

  1. 自己紹介
 中田 健誠 / Kyoto Uni (4th year)
 
 趣味でKubernetes(kube-scheduler)や


    周辺エコシステムにcontributeしています。
 
 Twitter: さんぽし (@sanpo_shiho)
 GitHub: @sanposhiho
 member of Kubernetes / Kubernetes SIGs

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


    3. NodeInclusionPoliciesについて
 4. 現在のPod Topology Spreadの仕様における問題点/課題点 (2)
 5. MinDomainsについて

  3. topologyKey
 well-known labelと呼ばれるものがあり、それが使用されてることが多い (多分)
 例:
 kubernetes.io/hostname:    Nodeの名前を示すラベル
 → 一つのNode

    = 一つのドメイン になる
 
 topology.kubernetes.io/zone: どのzoneに存在するかを示すラベル
 → 一つのZoneに存在する全てのNode = 一つのドメイン になる

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

    (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
 
 最もmatching Podが少なく存在しているドメインにおけるPodの総数のことを、内部実装 的にはglobal minimumと呼んでいる。

  5. maxSkew
 新しいmatching Pod(mypod)を作ったとする
 
 もし、zoneAにPodがスケジュールされると、
 zoneAのmatching Podの数: 3
 zoneBのmatching Podの数:

    1
 になる。Podの数の差は 3-1 > maxSkew(= 1) になってしまう。
 これはmaxSkewの制約に反するのでmypodは必ずzoneBのどちらかに行く

  6. 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/ ) より引用

  7. Skew計算時に対象にするNodeについて
 nodeAffinityでNode4が弾かれる場合、Skewの計算に入れてしまうと…?
 
 → matching Podの数が増えてもNode4のmatching Pod数は絶対に0(最小値)
 → topologyKey: kubernetes.io/hostname

    で DoNotSchedule を使用している場合、 matching Podの数が増えていくと、maxSkewに反するようになり、どのNodeにもスケ ジュールできなくなる。
 

  8. Skew計算時に対象にするNodeについて
 スケジュールできなくなる例: 右下の図だと、
 - nodeAffinityでNode4が弾かれる
 - topologyKey: kubernetes.io/hostname 
 -

    DoNotSchedule
 - maxSkew: 1
 の場合どこにも行けなくなる。
 公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用

  9. 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)

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


    - (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
 
 最もmatching Podが少なく存在しているドメインにおけるPodの総数のことを、内部実装 的にはglobal minimumと呼んでいる。

  11. 例
 topologyKey: kubernetes.io/hostname, 
 DoNotSchedule, 
 maxSkew: 1, 
 minDomains:

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

  12. 例
 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/ ) より引用
 ↓

  13. 具体的にどのようなことができるようになるか
 ClusterAutoscalerが使用されている場合で、複数のドメインにPodを配置したい場合、強 制的にNodeを増やすといったことができるようになります。
 例えば、
 - topologyKey: kubernetes.io/hostname 
 - DoNotSchedule


    - maxSkew: 1
 - minDomains: 5
 の時に、スケジュール可能なNodeが4つしか存在しない場合、5つ目のmatching Podの スケジュールは失敗する。こうして、matching Podのスケジュールを失敗させることで、 CAにNodeを増やさせることができる。