Podのリソース割り当ての推奨値を提案するKRR(Kubernetes Resource Recommender)

はじめに

こんにちは。3-shakeで技術顧問を勤めている青山真也(@amsy810)です。

3-shakeでは、CloudNative技術などを用いたSREの推進などを行っており、Kubernetesに関連した各種ソフトウェアへのキャッチアップなども積極的に行っています。

そこで、本連載では「OSS Insight」で公開されているソフトウェアや、最近話題になっているが、まだ詳細についてまとめられていないようなKubernetesに関連するツール・ソフトウェアを検証し、3-shakeのメンバーで紹介していきます。

第1回の今回は、Podのリソース割り当ての推奨値を提案する「KRR(Kubernetes Resource Recommender)」について紹介します。

「OSS Insight」 - Kubernetes Tooling

OSS Insightでは各種OSSのStatsなどがまとめて公開されており、各種OSSのトレンドがわかるようになっています。PingCAP社がTiDB Cloud上で提供しています。

カテゴリがいくつかありますが、Kubernetesを扱う際に便利なツール類は「Kubernetes Tooling」の項目にまとめられています。あくまでもKubernetesと直接関係のある「ツール類」が列挙されているため、「Prometheus」といった直接関係しないものや、ツールではなくデーモンプロセスが起動するようなソフトウェアは含まれていません。また、ツール類は自動的に検知しているのではなく、OSS InsightのGitHubリポジトリ上で管理されています。

Sysdigのレポートから見る
余剰リソースと最適化の必要性

近年のSysdigのレポートにもある通り、各組織のKubernetesのリソース割り当てには様々な問題が生じています。今回注目する部分として、CPUやメモリを過剰にコンテナに割り当ててしまっているケースが多発しています。クラスタの規模によって余剰なリソースの割合は異なりますが、CPUは約50〜80%・メモリは約20-30%のリソースが無駄になっているとの結果が出ています。

Kubernetesでは、コンテナに割り当てるリソースには最低限占有させる値(Requests)と上限値(Limits)の2つの閾値をもとに設定します。この値を設定する際に保守的に最低限占有する値を高く設定しすぎると、コンテナが利用しない余剰リソースも確保されたままになり、コストが高くなりすぎてしまうケースがほとんどです。アプリケーションのリリース当初は余裕を持ってリソースを割り当てることは良いと思いますが、定期的に実際のリソースの消費量を計測し、その値を元に最適化することが重要です。

こうしたコンテナに関わるクラウドコストの最適化は、Cloud FinOpsの活動の1つとしても注目されています。Cloud FinOpsを実現するものとしてはCloudNatixなどのSaaSもあります。SaaSによっては機械学習をもとにコンテナのリソースの推奨値を算出したり、Kubernetesノード自体の最適なインスタンスタイプ、RIなどの提案を行ったり、高度な最適化を行うこともできます。

KRR(Kubernetes Resource Recommender)

KRR(Kubernetes Resource Recommender)は、Kubernetes上で起動しているPodのCPU/Memoryリソースの推奨値を提案するツールです。Robusta社が開発しており、同社が提供しているRobustaというSaaSの一機能です。

KRRのアーキテクチャ

KRRでは、Prometheus(Thanos/Victoria Metrics/etc)などのメトリクスをもとに推奨値を計算します。対象のPrometheusはラベルベースでディスカバリーされるほか、CLIオプションで指定することもできます。kubectl port-forwardコマンドを利用して接続することもできます。

KRRを利用するにはkrrコマンドを利用します。例として、monitoring Namespaceのコンテナのリソースの最適値を調べる場合は「krr simple -n monitoring」コマンドを実行します。simpleサブコマンドは計算するときにsimpleなロジックを利用します。現在はsimpleロジックしか提供されていませんが、今後はいくつかのロジックが追加されていくことが期待できます。

コマンド実行後、数秒で推奨されるRequest値やLimit値が提案されます。どの程度余剰になっているのか・不足しているかなども合わせて表示されるため、優先度を付けて対応することもできます。今回の例では、多くのPodで余剰なリソースが割り当てられている・Prometheusコンテナへの割り当てが低いということが確認できます。

計算ロジックについて

現在提供されているsimpleロジックでは、CPUとMemoryの推奨値を下記のロジックで算出します。

• CPU：Requestに過去1週間の 99 percentileの値、Limitsは指定しない
  • Limitsが設定されていないため、残りの1%の最大値はバーストして利用可能
• メモリ：過去1週間の最大値に15%のバッファを追加した値
  • ※ README上は5%になっていますが、コード上は15%になっています

これらのロジックに関する閾値は「krr simple」コマンドのオプションとして制御できるようになっています(e.g. –history-duration/–cpu_percentile/–memory_buffer_percentageなど)。

VPAとの比較

コンテナに割り当てるリソースを最適化するOSSとして、他にもKubernetes Upstreamで開発されているVPA(Vertical Pod Autoscaler)などがあります。HPA(Horizontal Pod Autoscaler)ではPodのスケールアウト・スケールインを行っていましたが、VPAではコンテナのスケールアップ・スケールダウンを行います。

VPAを利用するには、KubernetesにVPA用のシステムコンポーネントを追加でデプロイする必要があります。一方でKRRはVPAとは異なり、クラスタにPrometheus(または互換実装)以外のコンポーネントをインストールする必要はありません。そのため、当然VPAリソースを作成するといった作業も不要です。

また、VPAでは最適値の結果を取得するために、VPA導入後に一定期間のデータ収集が必要です。一方でKRRは既にPrometheusに蓄積されたデータを元に最適値を計算するため、結果を即時に取得できます。将来的には、KRRの拡張機能やカスタムリソース・カスタムメトリクスのサポートなども実現される予定です。

なお、VPAには算出された最適値へ自動的に変更するオートスケール機能がありますが、KRRには現在ありません。In-place Pod Autoscaleの機能などもVPAではサポート予定ですが、KRRではその辺りがどういった仕様になるかも注意が必要そうです。

Robustaとの連携

KRRは単体で利用できますが、前述したRobustaと組み合わせて利用することで、より便利に利用することもできます。Robustaと合わせて導入することで、WebUIを元にKRRを利用できたり、定期的にKRRの結果をまとめてSlackチャンネルなどにレポートができます。リソース割り当ての継続的な調整を行う場合には、Robustaを合わせて利用することも検討すると良さそうです。

おわりに

第1回目の今回は、OSS Insightにも名前が載っていたRobusta KRRについて紹介しました。Kubernetesの利用を始めた当初はリソース割り当てが最適化されていなくても仕方がないかもしれませんが、ある程度安定して運用できるようになってきたらコストのためにも最適化することは重要です。最近では円安の影響でパブリッククラウドのコストも高騰しており、こうした活動が事業活動に与える影響も大きくなっています。

そのため、今回紹介したKRRを利用したり、PrometheusやGrafanaを用いて適切なダッシュボードを作成したり、高機能なSaaSとしてCloudNatixなどを導入したりすることで、リソース割り当てを最適化する取り組みについても、ぜひ検討してみてください。