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

KSM はシャーディングに対応しており、自動でも手動でも利用できます。残念ながら、自動シャーディングはまだまだ開発途上です。

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

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

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

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

他でも同様の手法が取られているようですし、当面はこれでうまくいきそうです。