概要
弊チームで利用しているマイクロサービスをKarpenter Nodeへの移行検証を行った際に、consolidationPolicyの違いについて色々学んだので本記事でまとめます．
Kapenterとは
Karpenterは，KubernetesのNodeを自動的にプロビジョニング及び管理するためのOSSオートスケーリングツールです．AWSが主導で開発をしており，今年の8月にv1.0.0がリリースされています．
v1.0.0がリリースされたことで，以下の資料等で詳しい仕組みや進化点などが書かれています．
consolidationPolicy
KarpenterのDisruption機能はconsolidationPolicyの設定によってNodeの最適化やNode削除の動作に違いがあります．consolidationPoicyはWhenEmptyとWhenEmptyOrUnderutilizedが用意されているため，その2つのpolicyの違いについて取り上げます．
詳しく知りたい方は以下のドキュメントを参照してください．
WhenEmpty
KarpenterのWhenEmptyポリシーは，Node上から全てのワークロードpodが退避した場合に，そのNodeを自動的に削除するPolicyです．
spec:
disruption:
consolidationPolicy: WhenEmpty
consolidateAfter: 1h
この設定では，Node上のワークロードPodが完全に退避してから1時間後に，そのNode削除を行います．注意点としては，Daemonsetやkube-systemにあるPod等は考慮されません．
以下の図は設定に基づいたWhenEmptyの動作を示しています．
WhenEmptyOrUnderutilized
上で紹介したWhenEmptyに加えてNodeの使用率も統合の観点とするpolicyです．
Nodeが空になるのを待つだけでなく，リソースの使用率が低いNodeがある場合に，Podを別Nodeに移行し，その後Node削除を行います．
そうすることで，リソース最適化だけでなくコスト削減も行うことができます．
設定例は以下の通りです．
spec:
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 1h
以下の図についても説明します．
BeforeではNode2とNode3がリソースを余らせている状態です．そうするとconsolidateAfterで設定した1h後にKarpenterはNode3にあったPodをNode2へ移行してNode3は削除させます．
こうすることでNodeリソースだけでなくNode数の最適化によるコスト削減が行えます．
選ぶ際の基準
WhenEmptyの場合
- バッチ処理やJob系のPod
- すぐに役割を終えるJobなどはWhenEmptyで十分
- Job完了のタイミングに合わせてNode削除することで無駄なリソースの削除も行える
ただし以下の様な制限もあります
- 常駐するPodがある環境では、Node間でのPod移動による最適化が行われない
- リソース使用率が低くても、Podが存在する限りNodeは維持される
WhenEmptyOrUnderutilizedの場合
- Podの集約してコスト削減を狙いたい場合はこのPolicy一択
- Node数の最適化も行ってくれるのでPod数が変化する環境でも対応できる
しかし以下のような注意点もあります．
- Karpenterは古いPodを削除すると同時に新規Podをスケジュールする
- Rolling Update形式ではないので，新旧Podの切替時にダウンタイムが発生する可能性がある
- 特に1PodのみでRunningになるのも遅い場合は，その間のダウンタイムが発生する
- https://github.com/kubernetes-sigs/karpenter/issues/1599
- これはissueとして取り上げられているので，対応を期待したい．
まとめ
今回はKarpenterのconsolidationPolicyの動作の違いについてまとめました．
Karpenterはまだv1.0.0がリリースされたばかりで改善点は多いと思いますが，非常に挑戦的で面白いOSSだと思うので動向を注視していきたいです．