Kubernetes Cluster Autoscaler — 乗りかかった船（前半）

Cluster Autoscalerに関する記事です。長い記事なので前半と後半に分けて投稿いたします。今回は前半です。

先週、別の部門の同僚と興味深い会話をしました。その中で、私たちはKubernetesクラスタの未知のワークロードサイズに対するインスタンスタイプと計画について話していました。同僚は、私のチームがクラスタで実行するインスタンスタイプを決定するために使用しているメモリとCPUの比率を尋ねてきました。なぜ比率が重要ではないのかを話さなければなりませんでした。というのも私はcluster-autoscalerを使っていたからです。ただ私は少し一歩下がって、Kubernetes上でワークロードを実行するときに使用している哲学について説明する必要があることに気がつきました。その時の話ですが、面白いブログ記事になるかもしれないと思ったので、ここで紹介します。

多くの人と同じように、私が管理しているKubernetesクラスタは、複数のapiserversやetcdなどのコントロールプレーンのために kubeadmによって設定されたように見えます。etcd を別の VM ティアーで実行しているかもしれませんし、していないかもしれませんが、全体的にはみんな同じようにやっています。興味深いのは、ワーカーノードです。1つのインスタンスタイプを実行する人もいれば、複数のタイプを実行する人もいます。クラスタのサイズを固定している人もいれば、クラスタオートスケーラーを実行している人もいます。タイトルからも分かると思いますが、私は cluster-autoscaler を使用している人の一人であり、ワークロードのために cluster-autoscalerに大きく依存しています。

過度に単純化した視点から見ると、クラスタオペレータとしては、誰かがアプリケーションのためにメモリやCPUに何を要求しても気にしません。私は SRE やビジネスの観点から非常に気にしていますが、とりあえずそれらは無視しましょう。

重要なのは、Scheduler が要求されたワークロードをスケジューリングできることです。

私にとって重要なのは、クラスタがそれに依存するワークロードを実行するためのリソースを持っていることです。明らかに、ある日何かが必要になった場合に備えて何千ものノードを稼働させることはできません。cluster-autoscalerは、リソースが利用できないためにPodがスケジュールに失敗したときに監視し、それらのリソースが利用可能になるようにクラスタノードをスケーリングします。また、利用率の低いノードのワークロードを再スケジュールして、クラスタのサイズが小さくなるようにスケーリングします。AWS上ではノードテンプレートやAWS AutoScalingGroupsを使ってスケーリングを行うことができ、私の環境ではAutoScalingGroupsに大きく依存しています。