cluster-autoscaler

ソースコード見ながら挙動の概要を把握する

以下、READMEから引用
Cluster Autoscaler is a tool that automatically adjusts the size of the Kubernetes cluster when one of the following conditions is true:
there are pods that failed to run in the cluster due to insufficient resources.
there are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes.
まとめると、ノードが不足していて特定のPodが配置できないときにノードを自動でスケールアウトしてくれたり、ノードが余剰になっていてそのノードで稼働しているPodが別のノードで動作できる状況であれば自動でノードをスケールインしてくれるツール

main関数
まず、以下の部分でログなどの各種設定を初期化している
最初の方では、Leader ElectionではNodeの増減を行うcluster-autoscaler君をどこのノードで動かすかを決めている。あとは各種フラグをコマンドラインに追加している。

内容としては、以下のようなエンドポイントにリクエストが来た際にデータを返すように設定している
-
/metrics
:メトリクスデータを返すエンドポイント -
/snapshotz
:デバッグ情報を返すエンドポイント(有効なら設定される) -
/health-check
:ヘルスチェックの結果を返すエンドポイント
最後に指定のアドレスでサーバーを起動して、リクエストを受け付ける

Leaderが決まっていない=LeaderElectがtrueの場合は、elseでノードを決定してそこでrun関数を実行する

そのrun()関数で実際にautoscalerの起動とスケールイン・スケールアウトの処理が行われている
↓下記の部分でcluster-autoscalerを起動して、シグナルハンドラの設定と、ヘルスチェックが稼働している
↓バックグラウンドタスクを実行
frequentLoopsEnabled
が有効な場合は、無限ループの中でRunAutoscalerOnce
を前回実行時間を参照して実行する。無効な場合は、一定期間sleepしてRunAutoscalerOnce
を実行する無限ループが走る。

RunAutoscalerOnce
では、ヘルスチェックステータスやメトリクスのデータを更新しつつ、autoscaler.RunOnce
(後述)を実行している

RunOnce関数の挙動については以下のブログに詳しく載っている

Podの配置ロジック(ノードをいくつ増やせばいいか)にはBinpacking Algolithmを用いている

Q. スケールアウトの際に、PodがUnscheduledになってからではタイミングとして遅くないのか。Nodeの空き容量が少なくなってきた時点で早めにスケールする(like HPA)ようなことはできないのか。
A. Cluster Autosaclerの場合は基本的にそういった仕組みはない。あくまでもPodのPendingを起点にトリガーされる。しかし、対処法はいくつか存在する。
有名な方法は、役割のないPodを用意する方法だ。
Nodeの利用率については、PodのCPU利用率ではなく、PodのRequest値によって決まるものである。そのため、ある程度のRequest値を持った空のPodをデプロイしておくことで、実際よりも多くのRequest値があるように見せることができる。
先のブログに上記のような記載があった
これによく使われるコンポーネントが cluster-overprovisioner
ベースになっているのは cluser-proportional-autoscaler(これもそのうちコード読みたい)

ザッとこんな感じかな
また気になったことがあったら追記する