provisioning: + NodeGroupのような概念はなく、直接provisioningするNodeを管理する + またKarpenterによって起動された訳ではないNodeはScaleDownしない + Scheduling enforcement: + kube-schedulerを介さずにbinpackingしたPodを provisioningしたNodeにKarpenterが直接スケジュールする + なので例えばCSIStorageCapacityの情報など、kube-schedulerであればScheduling Frameworkがスケジューリング可能かをチェックするような厳密なチェックを⾏わずに スケジューリングを⾏う + Designed to handle the full flexibility of the cloud: + クラウド側インスタンスタイプの柔軟な選択が可能 logo: https://github.com/aws/karpenter/blob/v0.7.3/website/static/logo.png
b. First Fit Decreasing bin-packing approximation algorithmを⽤いたPodのスケジューリング に必要なNode数のシュミレート 3. シュミレートした結果、1つ以上のPodがスケジューリング可能であれば、ScaleUp対象の NodeGroup候補に加える
選ばれたNodeGroupでシュミレートした追加Node数を追加した結果、”--max-nodes-total” オプションで設定した数を超過する場合にはSaleUp処理を中断する 6. “--balance-similar-node-groups”オプションをtrueに設定していた場合、以下の条件を満たす NodeGroupが類似NodeGroupとしてScaleUp対象のNodeGroupに追加される a. 選定されたNodeGroupとリソース容量が類似してる b. (⼀部を除いた)ラベル情報が⼀致してる c. 選定されたNodeGroupにスケジューリング可能なPodをすべてスケジューリングできる d. NodeGroupがScaleUp可能な状態である
b. 対象NodeGroupの現在のNode数がNodeGroupの最⼩値に達していないこと 3. ScaleDown候補Nodeリストを更に以下の条件でフィルタリングする a. ”ToBeDeletedTaint”Taintを持っていたら除外 b. “cluster-autoscaler.kubernetes.io/scale-down-disabled”=true annotationを持っていたら 除外 c. Nodeリソース(GPU or CPU or Mem)の中で最も使⽤率の⾼いリソースの使⽤率が⼀定値を超 えていたら除外
Podではない b. DaemonSet Podではない c. ReplicaSetやJobなどに紐付いていない d. 削除中のPodではない e. Terminal State Podではない f. HostPathまたはEmptyDirのボリューム(=LocalVolume)を使⽤していない g. Podに紐づくPDBがある場合、紐づくPDBのpdb.Status.DisruptionsAllowedが1以上であること h. etc (複雑過ぎて書ききれない) 5. ScaleDown候補NodeをemptyNodeと⾮emptyNodeに分割