Slide 1
Slide 1 text
Pod Topology Spreadの超最前線
MinDomains(仮)、NodeInclusionPolicies(仮)について
Kensei Nakada @sanposhiho
1
Slide 2
Slide 2 text
自己紹介
中田 健誠 / Kyoto Uni (4th year)
趣味でKubernetes(kube-scheduler)や
周辺エコシステムにcontributeしています。
Twitter: さんぽし (@sanpo_shiho)
GitHub: @sanposhiho
member of Kubernetes / Kubernetes SIGs
Slide 3
Slide 3 text
今日話すこと
Kubernetesのv1.24でPod Topology Spreadに新たに二つのAPIが追加されます。
今日はそれぞれのAPIの提案内容と、現状のPod Topology Spreadにおける課題点/問
題点や関連する細かい仕様を紹介します。
「v1.24だったらまだ先だしキャッチアップはまだ大丈夫だね〜」と思っているそこのあな
た、
Pod Topology Spreadで痛い目を見る可能性がありますよ 👀👀
Slide 4
Slide 4 text
注意点
今日話すMinDomainsとNodeInclusionPoliciesに関しては、
現時点(2022/02/21)で、KEPがImplementableになり、alphaとしてv1.24で公開される予定
となっているものです。
しかし、予定に狂いが生じたり、現在の提案に変更が加わる可能性があります。
実際にリリースされた時には、この資料ではなく、公式のドキュメントを参考にして下さ
い。
Slide 5
Slide 5 text
もくじ
1. Pod Topology Spreadってなんだっけ?
2. 現在のPod Topology Spreadの仕様における問題点/課題点 (1)
3. NodeInclusionPoliciesについて
4. 現在のPod Topology Spreadの仕様における問題点/課題点 (2)
5. MinDomainsについて
Slide 6
Slide 6 text
Pod Topology Spreadってなんだっけ?
6
Slide 7
Slide 7 text
Pod Topology Spreadってなんだっけ?
ゾーンやノードなどの任意のドメイン間でPodをどのように分散させるかを
制御できる機能。
Kubernetes v1.19で追加された比較的新しい機能です。
Slide 8
Slide 8 text
Pod Topology Spreadってなんだっけ?
pod.spec.topologySpreadConstraintsを通して設定する。
(KubeSchedulerConfigurationにてデフォルト値を設定することも可能 (beta))
公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用
Slide 9
Slide 9 text
topologyKey
Nodeのラベルのkeyを示している、
特定のラベルの値が同じNodeたちが一つのドメインとして扱われる。
Slide 10
Slide 10 text
topologyKey
well-known labelと呼ばれるものがあり、それが使用されてることが多い (多分)
例:
kubernetes.io/hostname: Nodeの名前を示すラベル
topology.kubernetes.io/zone: どのzoneに存在するかを示すラベル
Slide 11
Slide 11 text
topologyKey
well-known labelと呼ばれるものがあり、それが使用されてることが多い (多分)
例:
kubernetes.io/hostname: Nodeの名前を示すラベル
→ 一つのNode = 一つのドメイン になる
topology.kubernetes.io/zone: どのzoneに存在するかを示すラベル
→ 一つのZoneに存在する全てのNode = 一つのドメイン になる
Slide 12
Slide 12 text
labelSelector
そのConstraintで対象とするPodを見つけるためのlabelSelector。
labelSelectorと一致するPodはPod Topology Spreadの内部実装では
”matching Pod”と呼ばれることがある。
つまり:
“matching Pod” = labelSelectorに一致するPodで、すなわちそのConstraintで対象とな
るPod
Slide 13
Slide 13 text
whenUnsatisfiable
DoNotSchedule と ScheduleAnyway のどちらかの値を取る。
DoNotSchedule: 制約を満たせないNodeには絶対にPodをスケジュールしない
ScheduleAnyway: 制約を満たせないNodeにはPodをスケジュールしないように頑張る。
(= 制約を満たせないNodeにPodがスケジュールされることもある)
(Scheduling Framework的には、FilterするかScoreするかという違いです。)
Slide 14
Slide 14 text
maxSkew
ドメイン間のmatching Podの偏りをどれだけ許容するかを示す。
skew =
(最もmatching Podが多く存在しているドメインにおけるPodの総数)
- (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
Slide 15
Slide 15 text
maxSkew
ドメイン間のmatching Podの偏りをどれだけ許容するかを示す。
skew =
(最もmatching Podが多く存在しているドメインにおけるPodの総数)
- (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
最もmatching Podが少なく存在しているドメインにおけるPodの総数のことを、内部実装
的にはglobal minimumと呼んでいる。
Slide 16
Slide 16 text
maxSkew
maxSkewが1で、whenUnsatisfiableはDoNotScheduleとする。
(青色で示されているPodはmatching Pod。)
公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用
Slide 17
Slide 17 text
maxSkew
新しいmatching Pod(mypod)を作ったとする
もし、zoneAにPodがスケジュールされると、
zoneAのmatching Podの数: 3
zoneBのmatching Podの数: 1
になる。Podの数の差は 3-1 > maxSkew(= 1) になってしまう。
これはmaxSkewの制約に反するのでmypodは必ずzoneBのどちらかに行く
Slide 18
Slide 18 text
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/ ) より引用
Slide 19
Slide 19 text
現在のPod Topology Spreadの仕様における
問題点/課題点 (1)
19
Slide 20
Slide 20 text
Skew計算時に対象にするNodeについて
nodeAffinity/nodeSelectorはSkewの計算時に考慮される。
例:
PodがnodeAffnityで絶対にNode4にスケジュールされないようになっている場合
↓
Node4がドメインの中に入っていたとしても、Skewの計算から弾かれる
Slide 21
Slide 21 text
Skew計算時に対象にするNodeについて
nodeAffinityでNode4が弾かれる場合、Skewの計算に入れてしまうと…?
→ matching Podの数が増えてもNode4のmatching Pod数は絶対に0(最小値)
→ topologyKey: kubernetes.io/hostname で DoNotSchedule を使用している場合、
matching Podの数が増えていくと、maxSkewに反するようになり、どのNodeにもスケ
ジュールできなくなる。
Slide 22
Slide 22 text
Skew計算時に対象にするNodeについて
スケジュールできなくなる例: 右下の図だと、
- nodeAffinityでNode4が弾かれる
- topologyKey: kubernetes.io/hostname
- DoNotSchedule
- maxSkew: 1
の場合どこにも行けなくなる。
公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用
Slide 23
Slide 23 text
Skew計算時に対象にするNodeについて
しかし、TaintsとTolerationsは現状考慮されない。
一応ドキュメントの一番下にちっちゃく一行で
「tainted Node上のPodは考慮されます」
(= 言い換えると、普通のNodeと同じように扱う ということですね)
って書かれている。
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
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)
Slide 27
Slide 27 text
NodeInclusionPoliciesについて
27
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
NodeInclusionPolicies (KEP-3094)
Pod Topology SpreadのそれぞれのConstraintにおいて、
どのNodeを対象とするのかを指定できる機能
PodSpec.TopologySpreadConstraintにNodeInclusionPolicies APIが新たに追加され、
NodeAffinityとNodeTaintをそれぞれ適応するかどうかを指定できる。
Slide 30
Slide 30 text
↓こんな感じ
Slide 31
Slide 31 text
先程の問題
先程の問題はNodeInclusionPoliciesでNodeTaintをRespectに指定することで、解決でき
る
(後方互換性のために、提案ではNodeInclusionPoliciesのNodeTaintに関しては、デフォ
ルトがIgnoreになる。)
Slide 32
Slide 32 text
現在のPod Topology Spreadの仕様における
問題点/課題点 (2)
32
Slide 33
Slide 33 text
[再掲] Pod Topology Spreadってなんだっけ?
ゾーンやノードなどの任意のドメイン間でPodをどのように分散させるかを
制御できる機能。
Kubernetes v1.19で追加された比較的新しい機能です。
Slide 34
Slide 34 text
maxSkewに関して
Skewは存在しているドメイン間のmatching Podの数の差で計算される。
↓
maxSkewはあえて抽象的に言うと
「すでに存在しているドメインの間で、どのようにPodを拡散するか」
を制御するAPIである。
Slide 35
Slide 35 text
maxSkewに関して
Skewは存在しているドメイン間のmatching Podの数の差で計算される。
↓
maxSkewはあえて抽象的に言うと
「すでに存在しているドメインの間で、どのようにPodを拡散するか」
を制御するAPIである。
↓
ドメイン自体の数を制御(増やしたり減らしたり)したい場合はどうするの…?
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
MinDomains について
37
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
MinDomains (KEP-3022)
Pod Topology SpreadのそれぞれのConstraintにおいて、
ドメインの最小値を指定できる機能。
PodSpec.TopologySpreadConstraintにMinDomains APIが新たに追加される。
DoNotScheduleのみで使用可能。
Slide 40
Slide 40 text
↓こんな感じ
Slide 41
Slide 41 text
[再掲] maxSkew
ドメイン間のmatching Podの偏りをどれだけ許容するかを示す。
skew =
(最もmatching Podが多く存在しているドメインにおけるPodの総数)
- (最もmatching Podが少なく存在しているドメインにおけるPodの総数)
最もmatching Podが少なく存在しているドメインにおけるPodの総数のことを、内部実装
的にはglobal minimumと呼んでいる。
Slide 42
Slide 42 text
MinDomains (KEP-3022)
MinDomainsが指定された場合、ドメインの数が、MinDomainsよりも少ない場合に、global
minimumが常に0となる。
Slide 43
Slide 43 text
例
topologyKey: kubernetes.io/hostname,
DoNotSchedule,
maxSkew: 1,
minDomains: 5
とする。
4つ目まではスケジュールできるが、
5つ目のmatching Podはスケジュールに
失敗する。
図は公式ドキュメント( https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ ) より引用
↓
Slide 44
Slide 44 text
例
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/ ) より引用
↓
Slide 45
Slide 45 text
具体的にどのようなことができるようになるか
ClusterAutoscalerが使用されている場合で、複数のドメインにPodを配置したい場合、強
制的にNodeを増やすといったことができるようになります。
例えば、
- topologyKey: kubernetes.io/hostname
- DoNotSchedule
- maxSkew: 1
- minDomains: 5
の時に、スケジュール可能なNodeが4つしか存在しない場合、5つ目のmatching Podの
スケジュールは失敗する。こうして、matching Podのスケジュールを失敗させることで、
CAにNodeを増やさせることができる。
Slide 46
Slide 46 text
MaxDomainsはないの?
現状はないです。
議論のテーブルには上がりましたが、「強く必要とされるようなユースケースが思いつか
んし、一旦おいとこ」となっています。
Slide 47
Slide 47 text
何でScheduleAnywayで使えないの?
技術的な面で言うとパフォーマンス的なところで心配があったためです。
(現在のドメイン数を計算するのがちょっと大変で、PreScoreでその計算を挟むことに懸
念があった。)
また、その技術面の懸念を押し切るほど有用なユースケースがないためでもあります。
Slide 48
Slide 48 text
まとめ
- Pod Topology SpreadにTaintsを考慮させることが現状はできないことから、v1.24で
NodeInclusionPoliciesが導入される。
- 現時点でDoNotScheduleを使っている人は Nodeの削除時などtaintsの扱いに注意が必要 。
- Pod Topology Spreadにドメイン自体の数を制御させることができないことから、
v1.24でMinDomainsが導入される。