概要

弊チームで利用しているマイクロサービスを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だと思うので動向を注視していきたいです．