1. はじめに
この記事は筆者の学習用のアウトプットであり、誰かのインプットを想定して記述しない。
Podのスケジューリングについて、学習した内容を整理する。
2. Nodeの指定
2.1 Node selector
Nodeに付与されているラベルを指定して、Podをスケジューリングする。
例: disktype: ssd
Node selectorの場合、上記ラベルが付与されているNodeがない場合はPodがスケジューリングされない。
Node障害に弱いため、後述のNode affinityがある。
2.2 Node affinity
Node selectorとは違い、柔軟にNodeを指定することが可能である。
affinity.nodeAffinityいかに、次の2つを指定することで、柔軟にNodeを指定することができる。
-
requiredDuringSchedulingIgnoredDuringExecution :
Node selectorと同様に、対応するNodeがない場合はPodがスケジューリングされない。(Nodeの指定方法はより柔軟に指定可能) -
preferredDuringSchedulingIgnoredDuringExecution :
対応するNodeがない場合でも、適当なNodeにスケジューリングされる。
こっちを選択した場合はweightの指定が必要であり、複数preferredDuringSchedulingIgnoredDuringExecutionを指定したときに、各条件をもとに重みづけっし、一番weightの合計が高いNodeにスケジューリングされる。
2.3 Pod Affinity/Pod Anti-affinity
前述の方法はNodeのラベルに基づいたスケジューリングであったが、Pod Affinity/Pod Anti-affinityはNodeにスケジューリングされているPodのラベルに基づいてスケジューリングする。
ユースケースとしては、Podの冗長化として、既に同じアプリが乗っているNodeには新しく起動するPodをスケジューリングしないようにすることだ。
※ Pod Topology Spread Constraintsでも代替可能
Pod Anti-affinityを使用すると、特定のラベルがついているPodが割り当てられているNodeにはスケジューリングしない設定が可能。
※ topologyKeyにzoneを指定すればデータセンターへのPod配置も冗長化可能。上記はkubernetes.io/hostnameを指定
2.4 Pod Topology Spread Constraints
Pod Anti-affinityよりも後発のため、柔軟に設定できる。Pod anti-affinityはpreferredDuringSchedulingIgnoredDuringExecutionを指定するとPod数がNode数を超えてからは制御できず、単一Nodeに偏る可能性もある。
一方でPod Topology Spread ConstraintsはtopologyKeyを使用し、Pod分散を設定でき、Node数をPod数が超えても分散可能である。(maxSkewの値と実際のNode上のPod数との差分からどのNodeにスケジューリングするかを決める)
2.5 Taint/Toleration
TaintはNodeに対する設定、TolerationはPodに対する設定である。
Taintを使うと、Node側でスケジューリングするPodを制御できる。
Taintに対応したTolerationを設定したPod以外スケジューリングされないといった設定ができる。
Podスケジューリングができない場合はこのTaintを疑うのもよいかもしれない。