クラスタが大きくなると、スクレイピングに時間がかかるようになることがあります — ノードやPodなどの数によっては、kube state metricsが数百万ものサンプルを公開していることもあるのです！

KSMは自動でも手動でもシャーディングをサポートしています。残念ながら、自動シャーディングはまだまだ開発途上です。

自動シャーディングにより、各シャードはStatefulSetとしてデプロイされた際に自身の本来の位置を検出できるため、シャーディングの自動設定に役立ちます。これは実験的な機能であり、予告なく壊れたり削除されたりする可能性があります。

ということで、手動でシャーディングすることもできます！ただ、これもあまり良い方法とは言えません。というのも、複数のPodが同じリソースをスクレイピングする場合でも、それぞれがすべてのデータを取得する必要があるからです。つまり、1つのPodがxのデータをpullしていた状態から、n個のPodがそれぞれxのデータをpullする状態になるわけです。言い換えれば、シャードごとに必要なデータだけを転送できればn * x/nで済むところが、合計でn * xものネットワーク転送が発生することになります。やはり理想的とは言えません。

各シャードは、オブジェクトがそれぞれのkube-state-metricsのインスタンスによって処理されるかどうかを判断します。つまり、シャーディングされていたとしても、すべてのkube-state-metricsインスタンスは、担当するオブジェクトだけでなく、すべてのオブジェクトについてネットワークトラフィックとオブジェクトのアンマーシャルにかかるリソース消費を負担することになるということです。

ここまでの検討で私が至った結論は、データタイプごとにシャーディングするという方法です。Podが最も多くのサンプルを公開する傾向があるため、まずはPodを分離するのが理にかなっています。そこで、Podのメトリクスを公開するDeploymentを1つと、それ以外のすべてを担当するDeploymentを1つ用意することにしました。

どうやら他でも同様の手法が取られているようで、今のところはうまく機能しています。