kubernetesの便利機能

Node selector

特定のNodeにのみスケジュールしたい時に使う。例えばSSDを使っているNodeにスケジュールしたいってとき、マニフェストに

Nodeselector:
    disktype:ssd

って書く。

Node Affinity

Affinity ＝類似性、　近づくようにする

Selectorとやることは近いけど、こっちは「可能ならスケジュールする」選択肢が取れる。Selectorだと対応するNodeが存在しない場合、PodがNodeにスケジュールされないが、Affinityなら適当なNodeにスケジュールするように設定できるので柔軟性が高い。
絶対に特定のNodeにスケジュールしたいって時以外はAffinityを使うのが無難。
設定が二つある。
requiredDuringSchedulingIgnoredDuringExecution：対応するノードが見つからなければスケジュールされない。Selectorと比べてPodの指定を細かくできる
preferredDuringSchedulingIgnoredDuringExecution：できれば対応するNodeにスケジューリングするけど、なかったら適当にスケジュールする。

Preferredを指定した場合、Weightのしていが必要になる
複数Preferredを指定した時、各条件に重みをつけることで、各Weightの合計が高いNodeにスケジュールされる。

Pod Affinity(Anti-affinity)

NodeSelectorやNodeaffinityと違い、すでにNodeにスケジュールされたPodを基準に考える
例えば
すでにNodeAにPodAがスケジュールされている。
ここでPodBはPodAと同じNodeがいいと言っている。これがPodAffinity
しかしPodCはPodAと同じNodeは無理と言っている。これがPodAntiaffinity
よく使うケースとして、Node障害に備えて同じアプリケーションを動かしているPodを同じNodeに載せないという使い方がある。なぜか。いくらdeploymentでアプリケーションを冗長化させてもNodeがイカれたらアプリケーションが停止してしまうから

Pod Topology Spread Constraints(PTSC)

TopologyKeyを使うことでどうPodを分散させるかを表現できる。
例：Kubernetes.io/hostnameラベルを指定すると、ホスト間でPodを分散してスケジュールできる。
PodAntiaffinityではPreferrを指定しても、Podの数がNodeの数を超えると制御できなかった。
逆に完全に分散させようとRequireを使うとPodの数がNodeの数を超えられなくなる。
そこでPTSC
ポイントはmaxSkew:数字という指定。
これはNode間の差分が１以下になるようにスケジュールするという設定。
例えば三つNodeがあったとする時、全てのNode間のPodの個数の差分をみて、全体の差分が１以下になるようにスケジュールする

TaintとToleration

TaintはNodeに、TolerationはPodにつけるもの。
Taintは汚れ、Tolerationは寛容という意味。
NodeについているTaint（汚れ）をPodが許容できるかという考え方
Node Affinityでは 「あるPodをどういうNodeにスケジュールしたいか という考えだったが、Taint/Tolerationは 「あるNodeが特定のPodしかスケジュールしたくない（特に指定のないPodはスケジュールしたくない）」 という考え方になる
NodeにTaintをつける方法

kubectl taint nodes <対象ノード名><Label名>=<Labelの値>:<Taintの効果>

Pod priorityとPreemption

Podがスケジュールされる優先順位を決めることができる。
やりかた
1.Priorityclassを作成
2.設定したPriorityclassをPodのマニフェストに設定
①value:10000みたいに重みをつける。多いほど重要
②PriorityclassName:に①のMetadataの名前を書く

水平スケールと垂直スケール

アクセスが増えると一つのPodでは厳しくなる。スケールさせてアプリケーションを安定させよう。
水平スケール：同時に使えるアプリケーションを増やすこと
垂直スケール：使用できるリソースを増やすこと

Horizontal Pod Autoscale

HPAが自動でPodの個数を調整できる。
HPAのマニフェスト
minReplicasとmaxReplicasを指定。Podの増減の幅を決める。
増減を決めるメトリクスはMetrics以下に書く
targetaverageUtilizationには望ましいCPU使用率を書く

VPA

resource requests/limitsの値を自動で調整してくれる

アプリケーションの可用性を保証しよう

PodDisruptionBudget

DeploymentでカバーできるのはPodの更新のみ。Nodeのメンテナンスの時などにPodがどっか言ってしまったりする。それを安全に行う方法。
ポイント
minAvailable　「最低幾つのPodが利用可能な状態か」 を指定
maxUnavailable 「最大幾つのPodが利用不可な状態か」 を指定
例：deploymentのReplicas:3の時、必ず二つ以上のPodが利用可能な状態で存在してほしいという要件があったとする。
このときPDBはminAvailable:2と書く
例えば何らかの理由でPodが一つPendingになった時、同時にapp:hello-serverのPodが載っているPodからPodをどかせられなくなる。これによってNodeのメンテはPendingが解消されるまでできなくなるので、自動的にNodeが保たれる。